How to Diagnose HubSpot Form Submissions Going Missing

If a HubSpot form feed is dropping legitimate signups, the loss almost never happens in one place. It happens at three boundaries between your website form and the CRM: submissions the Forms API rejects before a contact is created, contacts that are created but flagged non-marketing so they never enter a marketing list, and email or consent gaps that create a contact you can neither mail nor report on. The one-line version: count the same cohort at each boundary, and the first place the number drops is your defect.

Key takeaways

The short answer: reconcile raw form entries against accepted submissions, then against created contacts, then against marketing contacts. The first drop in that chain is where you are losing people.
Since 21 March 2022 the Forms API rejects any submission that includes a field not on the form or omits a required field, returning a REQUIRED_FIELD or FIELD_NOT_IN_FORM_DEFINITION error with HTTP 400.
A submission without a populated email does not create a contact unless the account setting for email-less submissions is enabled, so a mismapped email field silently produces nothing.
Contacts created through the API or an integration default to non-marketing, while contacts created by a HubSpot or non-HubSpot form default to marketing. A feed that posts through the API therefore hides every new subscriber from your marketing lists.
The skipValidation parameter was deprecated in 2021 and will not rescue a broken payload, so the fix is correct field mapping, not bypassing validation.

What you need

Super Admin or a role with access to form settings, contact settings and the marketing contacts panel in the HubSpot portal.
Access to the source form platform's own submission log (Gravity Forms entries, a custom form's database table, or your middleware logs) so you have a ground-truth count.
If a custom or middleware feed posts submissions, the ability to read its HTTP request and response bodies, including 400 responses.
The portal ID and the form GUID for the affected form.

How to trace where a HubSpot form feed loses signups

Fix the numerator first. In the source platform, count raw submissions for a defined window, for example the last 30 days. This is the number every later stage must reproduce. Do not start from HubSpot's numbers, because they already sit downstream of the drop.
Count what HubSpot accepted. Open the form in HubSpot and read its submission analytics, or if a feed posts server to server, count the 200 responses in your own logs. Compare accepted submissions against the raw count. Any gap here is validation rejection, not a reporting artifact.
Read the rejection bodies. For a server-side feed, inspect the 400 responses. The HubSpot developer changelog for the March 2022 validation change confirms the endpoint now returns REQUIRED_FIELD when a required field is missing and FIELD_NOT_IN_FORM_DEFINITION when you post a field the form does not define. A single stray hidden field on your form will reject the entire submission.
Verify the payload matches the endpoint contract. The feed must post to submissions/v3/integration/submit/:portalId/:formGuid with a fields array of name and value pairs, and it should carry the visitor cookie in context.hutk so the submission associates to the right contact. The HubSpot Forms v3 submit endpoint reference documents the exact field, context and consent structure.
Check the email boundary. A submission with no populated email will not create a contact unless you enable the account setting described in HubSpot's guide to allowing submissions without email addresses to create contacts. The common defect is a source form whose email input is mapped to a custom property instead of the primary email field, which yields contacts with no address and no ability to be mailed.
Check the marketing-contact boundary, which is where half of them go. Per HubSpot's reference on default marketing statuses for created contacts, contacts created through the API or an integration default to non-marketing, while contacts created by a HubSpot or non-HubSpot form default to marketing. If your feed posts through the API, every new subscriber exists in the CRM but is invisible to any active list filtered on marketing status, which reads as signups disappearing. Set them as marketing on creation, or route through a real form submission.
Check consent and enumeration mapping. Map subscription opt-in through legalConsentOptions so the contact holds the subscription you intend to mail. For any dropdown, radio or checkbox mapped to a HubSpot enumeration property, the posted value must match an option's internal value exactly. A label that differs from the internal value is a silent per-field drop even when the submission as a whole succeeds.
Reconcile against an active list. Build an active list on "Form submission" for the form and the window, then compare its count to your raw numerator. Cross-check against your lead-quality reporting, since a silent drop here understates every downstream conversion rate.

Where the drop actually happens

Most "missing submissions" tickets collapse to one of four boundaries. Work them in order, because an earlier drop masks a later one.

Boundary	Symptom	Where to check	Signal
API validation	Submission never reaches HubSpot	Feed logs, form submission analytics	HTTP 400 with `REQUIRED_FIELD` or `FIELD_NOT_IN_FORM_DEFINITION`
Email mapping	Accepted but no contact, or contact with no email	Contact record, email property	Contact created with blank primary email
Marketing status	Contact exists but absent from marketing lists	Marketing contacts panel, active list count	New contacts flagged non-marketing
Consent and enumeration	Contact present but not subscribed or field blank	Subscription preferences, property history	Missing subscription or empty enumeration property

Marketing status by creation source

This single table explains most "the contact is there but nobody can email them" reports. The creation source, not the person, decides the default.

Creation source	Default marketing status	Effect on lists and sends
HubSpot form	Marketing	Enters marketing lists, can be mailed
Non-HubSpot form tracked by HubSpot	Marketing	Enters marketing lists, can be mailed
API or integration submission	Non-marketing	Created but excluded from marketing lists until changed

Troubleshooting

All submissions rejected with a 400 after nothing changed on your side. A required field was added to the form in HubSpot, so every historical payload now omits it. Diff the current form definition against your feed's field list.
Rejections mention a field you removed from the visible form. Hidden and dependent fields still count as part of the form definition. Remove the field from the payload or restore it to the form.
Contacts appear but never receive the welcome email. Check marketing status first, then subscription. A non-marketing contact will not receive a send even when the flow enrolls them.
Counts match in HubSpot but your source shows more. Deduplication is collapsing multiple submissions from one email or one cookie into a single contact. That is expected behavior, not loss, and you should count contacts plus repeat submissions separately.
You are tempted to bypass validation. The deprecation of the skipValidation parameter means that path is closed. Correct the mapping instead. If you have just taken over the portal, run a full inherited-portal audit before trusting any historical counts.

How to verify it worked

A fix is proven by numbers converging, not by the error disappearing from one screen. Confirm all four:

Accepted submissions in HubSpot equal raw submissions in the source platform for a fresh test window, within your known deduplication rate.
Your feed logs show zero 400 responses over that window.
New contacts from the form show marketing status where you intend to mail them, verified in the marketing contacts panel.
The active list built on the form's submissions equals your raw numerator, and a test submission using a real subscriber email lands in that list and receives the intended send.

Re-run the reconciliation weekly for a month. A feed that passes once can regress the moment someone adds a required field to the form, so the reconciliation, not the one-time fix, is the durable control.