May 25, 2018 4:04 PM
Now live, a new form submission endpoint is being released for the Forms API. The new endpoint now supports both CORS AJAX submissions and the new forms-related GDPR functionality. The existing form submission endpoint will continue to function as usual.
With the release of the new form submission endpoint, integrators can take advantage of two powerful new features:
legalConsentOptionsfield is used to indicate that the visitor submitting the form provided their consent for communications and processing. The details included in this field are described in the endpoint’s documentation (see below).
This feature is currently live; integrators can take advantage of the new form submission endpoint immediately. Check out the documentation for this endpoint here.The existing form submission endpoint will continue to function as usual.
Please don’t hesitate to post any questions or concerns in the comments below.
Feb 14, 2019 9:23 AM
I'm working on a catch all form solutions that posts to a single hubspot form.
I am using `'skipValidation' => true` when submitting data, and the huspot form has no configuration set for consent/gdpr or subscription types.
With the above in mind, can I dynamically submit `legalconsentOptions` by declaring this in when I submit data to the api or must the hubspot for be configured for a consent etc.?
Dec 5, 2018 4:28 PM
You're correct that the v3 Forms API does not auto-populate any
ipAddress value at this time.
Would any of these methods work for your purposes?
If you'd like to make a case for this feature to be added, please post on the HubSpot Community Ideas Forum with your use case. If you post, share the link below and I'll be happy to upvote it!
Isaac TakushiAssociate Certification Manager
Dec 4, 2018 8:10 PM
According to the docs for the v2 API "if no ipAddress is included, the IP address will be set to the IP of the system making the request to the Forms API". Not sure when this would be useful with v2, since AFAICT it would always be a server IP. With the v3 API supporting CORS requests, it seems like that behavior would be much more useful (especially since there isn't a particularly robust way to get a user's IP address from a JS app), but it doesn't seem to support auto-populating the IP address by default, resulting in the following warning message:
Is there any way to get the IP auto-populated from a JS/CORS request to the v3 API?
Jun 19, 2018 11:38 AM
@Derek_Gervais I too have the same questions as @mattdev.
Additionally, with the v2 endpoint, you could include pageId in hs_context and, while not documented, it would actually count those form submissions against a specified HubSpot landing page. This worked great for us because we could capture form metrics on landing pages even though we were using non-native forms. I understand this probably was not inttentionally supported to begin with, but it was massively valuable to us and is now sorely missed with the v3 endpoint. Would it be possible to bring this functionality back to v3?
Without this and what @mattdev mentioned, we are debating whether we should move to v3 or stick with v2 and use custom contact properties to capture consent data, and then workflow rules to populate legal_basis.
Thanks for your consideration,
Jun 21, 2018 1:33 PM
Hi @mattdev and @nflaherty
The new endpoint is designed to support server-side validation of the fields in the form, so that any submissions through the Forms API would be validated in the same way that submissions through HubSpot forms would be validated. The older endpoint processed submissions asynchronously, so it would be possible to send data or fields that wouldn't actually get updated for the contacts, and the new endpoint is designed to prevent that. That validation is enabled by default, but it can be bypassed using the
skipValidation option in the request data.
@nflaherty the new endpoint does not support the pageId, but we'll check with the forms team to see if that can be added.
Jul 31, 2018 10:37 AM
Hi @dadams, what did the forms team think of enabling pageId in the v3 endpoint? We will be going live with our implementation of v3 this week and are worried about the loss of analytics here. Knowing whether it is being considered or is in the pipe would ease our minds!
Jun 19, 2018 4:24 AM
What is the reasoning for requiring the posted data fields to match the fields in a built hubspot form?
In the existing endpoint (v2) you can create and empty form in hubpost and post data to it. If the posted field exists in hubpost contact properties, the data value is applied.
Can the v2 endpoint accept the gdpr related fields?
Jun 8, 2018 4:28 PM
@nflaherty that email type is the default type for in-app tools like sequences, and it's currently not accessible via the API. I'll touch base with the team for more information on how integrators using the forms API would/should work with that email subscription type.
@Fraggle this is a known issue, see the following topic:
I'm using the (still experimental) AJAX endpoint for forms API and I'm getting the following error on IE11: SEC7123: Request header content-type was not present in the Access-Control-Allow-Headers list. and this error on Firefox: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.hsforms.com/submissions/v3/integration/submit/[id]/[guid]. (Reason: missing token 'content-type' in CORS header 'Access-Control-Allow-Headers' from CORS prefligh…
Jun 7, 2018 5:49 PM
I can't seems to get it to work when using the Fetch api.
=> If I don't set the Content-Type header to application/json, the request is refused with a 415 error (wrong type of content)
=> If I DO set the Content-Type header, then the request is refused at the preflight stage with a "Request header field Content-Type is not allowed by Access-Control-Allow-Headers." which mean the server is not configured to allow this access control check for this header field.
Seems like there is an incoherence between the api headers expectations and the servers configurations to allow CORS requests.
That's my guess.
Let me know if you fix it or if I'm wrong in my analysis.
May 30, 2018 9:42 AM
Thank you for the new legalConsentOptions section in the Forms API. It is a great and very timely improvement for us. A quick question: We'd like to include the default "marketing info" subscription in our post to the form, but it and its ID doesn't seem to be included in the get_subscriptions GET call. How can I find the ID for this default subscription? Is it possible to include in the legalConsentOptions section?