Skip to main content
The Webhook/API call automation action sends an HTTP request to a public HTTPS endpoint.
Leadping automation webhooks do not currently include Standard Webhooks signature headers. Do not expect webhook-id, webhook-timestamp, or webhook-signature, and do not treat the built-in tracing headers as proof of origin.

​
Configure the action

Leadping rejects unknown template variables and an empty rendered body for POST, PUT, or PATCH.

​
Built-in request headers

Every request includes:
Use these values for logging and correlation. Because a caller can copy them, they are not authentication credentials.

​
Retries

When retries are configured, Leadping retries:
  • request timeouts and connection failures;
  • HTTP 408;
  • HTTP 429; and
  • HTTP 5xx responses.
Other non-success responses fail the action without a retry. A successful 2xx response completes it. The same automation run and action identifiers are reused across attempts. Design the receiver to deduplicate on those identifiers when repeating the side effect would be harmful.

​
Secure the receiver

  • Expose only an HTTPS endpoint intended for this integration.
  • Validate the expected content type and payload shape.
  • Reject unknown automation or action identifiers when your application can maintain an allowlist.
  • Apply request-size, timeout, and rate limits.
  • Log identifiers and response status without logging sensitive lead data.
  • Make processing idempotent.
Authentication headers such as Authorization, Cookie, Api-Key, X-Api-Key, and X-Leadping-Webhook-Token cannot be entered as ordinary action headers. If the receiver requires authenticated or signed delivery, do not rely on this action until Leadping exposes a supported credential or signing configuration for it.

​
Choose a receiver that fits the action

This action sends the method, headers, and body you configure; it is not a subscription with a fixed Leadping event payload. Agree on the payload with the receiver and use the variables available in the automation editor. Test the rendered output with the actual kinds of values it will contain, including quotes, newlines, and missing optional fields. Do not use an unsigned incoming request as authority to change access, transfer funds, send communications, or disclose private records. An allowlist of automation IDs helps detect mistakes but does not authenticate the caller. If the workflow requires proof of origin, arrange a supported authenticated integration before enabling it; do not hide a credential in the URL or body as a workaround.

​
Acknowledge and deduplicate deliveries

For a receiver appropriate to this action, store accepted work durably before returning 2xx. A 202 Accepted response is suitable when your receiver will process that work asynchronously. Leadping considers the delivery complete after a successful response; it does not track the receiver’s later job result. Use the automation, run, and action IDs together to correlate repeated attempts. Claim a delivery atomically in your own storage before applying a side effect so two concurrent attempts cannot both perform it. Return success for an already accepted duplicate. These IDs identify the delivery; they do not prove its origin.

​
Troubleshoot a failed action

Begin with retries disabled while checking a receiver. Before enabling retries, verify that submitting the same delivery twice produces only one accepted unit of work.