Configure a server-side HTTP action
Use a Webhook/API workflow action for a consistent call after every applicable submission. Configure the method, endpoint, headers and payload mapping. Keep tokens in named server configuration or connections; do not place credentials in public form JSON or hidden fields.
Send only the fields the receiver needs. Include the form and submission identifiers so the destination can correlate or deduplicate requests.
{
"submissionId": "{{submission:id}}",
"formTitle": "{{form:title}}",
"email": "{{field:email}}"
}
This is a payload template: use the action editor's token picker and verify the actual request body. The receiver's API contract determines property names and types.
Test the operational result
Use a QA endpoint first. Verify successful delivery, a rejected request, a timeout and an unavailable destination. Inspect the recorded workflow attempt rather than treating the visitor's thank-you message as proof of remote delivery.
Retries can repeat a request. Agree on an idempotency key and authentication with the receiver before using the workflow for payments or other non-repeatable operations.
When a script is appropriate
For branching payloads or a multi-step API exchange, use an approved C# recipe. The wizard includes a normal JSON webhook, a configured API call and an HMAC-signed webhook. Test run performs real requests, so select a QA destination.