Handling API response errors, how to display error messages AND keep the form page without the confirmation window, as well as not saving the data in Entries

I’ve developed a form specifically tailored for inputting client registration data to be transmitted via API to a third party. Below, I’ve detailed the overarching objective I aim to accomplish:

1. Currently, I’m grappling with displaying API errors directly within the form interface. My goal is to initiate a form submission error, exhibit the error message itself, and highlight the field necessitating correction. I’ll discuss two hooks I’ve employed for this purpose. Despite scouring through all available documentation, I haven’t identified a suitable hook for this task. Any recommendations or guidance to steer me in the right direction would be greatly appreciated.

2. Additionally, I’ve encountered an issue where Entries are generated in both scenarios. I’ve set the Email field to be unique, but when errors arise in other fields, subsequent submissions throw an error related to the Email field, as the address already exists in the database. I would be grateful if you could furnish a functional code example for deleting the record.

3. My experimentation with various hooks has led me to scrutinize the functionality of the ‘gform_confirmation’ hook. Unfortunately, I find its behavior unsatisfactory, as it replaces my form with its own confirmation. Furthermore, if there’s an error in one field, the logic of the confirmation isn’t coherent. A PopUp would offer a more preferable solution.

4. Furthermore, I’ve attempted to integrate validation with ‘gform_after_submission’, but I’ve encountered difficulty in displaying form submission errors through this hook. Even when deliberately triggering an API error, all submissions register as successful, disregarding the code, and storing the data in Entries.

5. The intended task involves a multi-page form structure, yet I’ve hit a snag at the initial step, constructing it as a single form for testing purposes. In essence, the logical flow of the form should entail: the client inputs data → selects a tariff plan → verifies their card → signs the agreement → reviews the receipt and entered data → and, contingent upon the tariff, they may either make an immediate payment or receive a payment invoice within 5 days. The submission of the first step should precede the agreement signing.

All custom validation handling can be done via the gform_validation filter.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

If you want to have a little more dynamic control over how the system responds to the API - especially without requiring the user to re-enter a lot of the data that led to the API call, you might want to look at Gravity Flow and it’s outgoing webhook step. In addition to having the option to define what next step an entry should go to based on the webhook response type (200/400/500), and mapping values from the API response back into the entry without code, there are a few extra filters like gravityflow_entry_webhook_response_mapping that let you modify in the specific cases or steps you need.

The same gform_validation or gform_field_validation filters also run on user input or approval steps which means you can focus on which fields should be editable for the assignee to update only in the case of failures.

Regards,
Jamie