Skip to main content
A webhook endpoint is an HTTPS URL that FlowSign POSTs to when something happens to a package or a recipient’s session. Endpoints belong to the organisation and receive events from every workspace.
Webhooks are included in the Enterprise plan. Managing endpoints, in the app or through the API, requires an organisation admin.

Creating an endpoint

In the app

Open Settings > Webhooks (my.flowsign.app/settings/webhooks) and add an endpoint:
  • Endpoint URL: must use https://.
  • Description: optional, for your own reference.
  • Events: tick the events to subscribe to. See Events.
After saving, the endpoint’s signing secret is shown once. Store it; you need it to verify deliveries and it cannot be read again. The same page lists each endpoint with its state (Active, Paused or Failing), lets you pause, resume, edit or delete it, and opens a delivery log you can search and filter by outcome.

With the API

secret is returned only in this response. GET, PATCH and DELETE /api/v1/webhooks/{endpointId} manage the endpoint afterwards; GET also returns its 25 most recent deliveries.

What gets delivered

Each delivery is an HTTP POST with a JSON body and three headers: The body has the same envelope for every event:
data differs per event; see Events. Every event’s data carries metadata, the package’s custom field values. Respond with any 2xx status within 10 seconds. Do the real work after you have responded; anything slower is treated as a failure and retried.

Verifying a delivery

Compute an HMAC-SHA256 of the raw request body (before any JSON parsing or re-serialisation) with the endpoint secret, hex-encode it, and compare it to X-FlowSign-Signature with a constant-time comparison.
The Python and C# receivers hand the payload to a background queue rather than processing it inline, so the response still goes out well inside the 10 second budget. Use X-FlowSign-Delivery-Id as an idempotency key: a delivery can arrive more than once if your endpoint responded slowly the first time.

Retries

If your endpoint returns a non-2xx status, times out, or cannot be reached, the delivery is retried with exponential backoff. The delays below are approximate: the queue adds random jitter to each one. After nine attempts, spread over roughly four hours, the delivery is marked exhausted and not retried. Each failed attempt increments the endpoint’s consecutive failure counter; a successful delivery resets it to zero. At 10 consecutive failures the endpoint is shown as Failing and is skipped for new events until you re-enable it. Resuming the endpoint in Settings, or PATCH /api/v1/webhooks/{endpointId} with { "enabled": true }, clears the counter. Pausing an endpoint stops deliveries without counting failures. Deliveries already queued for a paused endpoint are dropped, not retried.

Delivery log

Every delivery is recorded with its event, attempt count, the response status and body (first 1,000 characters) and any error. Read it from the deliveries panel in Settings > Webhooks, or from GET /api/v1/webhooks/{endpointId}, which returns the 25 most recent. There is no manual redelivery; if a delivery is exhausted, fetch the package with GET /api/v1/packages/{packageId} to catch up.