If in building this API request you are doing a lot of iterations, or are building similar use cases in the future, you may want to look at how Gravity Flow’s outgoing webhook provides some improved user experience for both developer and request processing.
-
No code?
If your CURL command is relatively straight forward you won’t have to write any code! Add the URL, field mappings and connection details into the step settings and the webhook step will handle the rest. That can even include mapping values back from the API response it receives into specific fields. -
Low code!
If you do have logic to add, the gravityflow_webhook_args filter lets you focus on the logic to change and let the automation handle the actual request/response processing. -
One click to re-run test cases
As the webhook call is now a step in the workflow, you can select to restart a step to repeat/test in contrast to potentially re-filling in all the fields and submitting a new form each time. -
Response code mapping / error handling
This step type lets you define what the next step in a workflow should be depending on the response type received (200/300/400/500). The dreaded “the 3rd party system we connected to had an outage or network connectivity issue and we need to figure out which entries need to be re-processed”. You could have any which fail route to a separate step assigned to your support team to investigate/resolve. -
Multiple ways to log in any environment
The same logging approach that @chrishajer linked you to will work in Gravity Flow as well. Plus, the timeline which displays at the bottom of each entry details page could either be customized (changing the default note via gravityflow_timeline_note_add) or add your own during code execution via
gravity_flow()->add_timeline_note( $entry['id'], 'custom message');
If you don’t want to turn on xdebug or full logging in a production system, but still get some details out of edge case code execution, the timeline can be a good alternate.
Cheers,
Jamie