Amendment to Forms API Submission Validation

Whats Changing?

Last year (February 2022), we announced some updates to our form submissions API that would make our customer’s accounts more secure, by requiring all fields be declared on the form definition before we would accept these fields in form submissions.

While we rolled this change out across the majority of customer accounts, a few customers were dependent on this behaviour for their day to day operations. We decided to not disrupt them, and to come up with a better understanding of their needs, before pressing forward.

For these customers, we are now including the option to not require all the fields on a form definition, if the client authenticates with our secure API. This new option should make it easier for customers to secure their accounts with minimum disruption.

How accounts have been impacted differently

To limit impact, back at the initial announcement, we split our customers into two groups based on their usage of our submission API.

1. The majority of customers, who were unaffected by this change.
   • These accounts have had these rules applied since last year, with the initial change log announcement.
2. The minority of customers, who would have been affected by this change.
   • For these customers, we did not apply the change at the time of the initial announcement. These accounts will be informed of the change to use the secure API via an in-app banner in the forms tool and an email to the account’s point of contact. These customers will see these validation rules applied from June 12th, 2023

What does this mean for developers in these notified accounts?

From June 12th, 2023, any new form integrations that submit to unlisted fields, that are CRM properties, on the form definition, without authentication, will need to move to using the secure variations of those APIs. Failure to do so will result in them receiving a client error with status 400 of FIELD_NOT_IN_FORM_DEFINITION for those unlisted fields.

• If a field, which is a CRM property, was submitted to a form before this new validation was rolled out, we will continue to allow that field to be submitted to that form without authentication, even if it’s not listed in the form definition
• If the field isn’t a CRM property, we will continue to allow it to be submitted as it has never, and will continue to not, be included in the properties for the resulting contact.
• When a field, which is a CRM property, but is not part of the form definition, is sent via the secure API, we skip the validation, as we trust the client. Integrators will need to perform checks on their side, to ensure that unwanted fields are not making their way through their unauthenticated APIs.

Even though fields that aren't part of the form definition will work with the secure API, we still recommend that all submitted fields be included in the form definition to make sure that it's clear what data the form should collect when viewing the form details.

Discuss this changelog on our community post located here.