Webhooks

Endpoints for webhooks under /api/v1/webhooks.

Endpoints

Listing webhooks

GET /api/v1/webhooks returns { webhooks[], links[] }; pass ?workflowId= to filter. Each links entry carries the public invoke URL. GET /api/v1/webhooks/{id} returns a single webhook. Generic webhooks are provisioned when you publish a workflow destination containing a webhook trigger (see Deploying). Production and previews have separate URLs.

Signed Sentry sources

An Admin or Owner can also prepare the endpoint from Manage versions → Add event source → Signed Sentry webhook in the selected workflow destination. Save the Sentry trigger's connection first, then choose the trigger and provide its organization and project slugs.

POST /api/v1/webhooks with provider: "sentry" requires workflowId, organizationSlug, projectSlug, and a workspace Sentry credentialId or signingSecret. To prepare a named destination, also pass executionTargetId and its saved Sentry trigger's nodeId. The new endpoint remains off until that destination is approved and published with the selected connection. Save the returned invokeUrl; only the token digest is retained for later reads.

Sentry invocation uses /api/integrations/sentry/{token} and requires the Sentry HMAC signature. Each destination owns its integration identity and deduplication receipts. Publishing updates the version behind the existing URL; switching off the destination stops ingress. The independent Sentry ingress feature switch must also be enabled.

Triggering a workflow

The public invocation endpoint lives outside /api/v1:

POST https://confluye.run/api/webhooks/<token>

The token is part of the URL — no bearer key is used to invoke it. All HTTP verbs are accepted (GET/POST/PUT/PATCH/DELETE). The payload is the JSON body (or query string for GET), merged with a _webhook object describing the method, query, and headers (sensitive headers like authorization, cookie, and x-api-key are stripped).

File payloads

JSON and signed-provider requests are bounded to 10 MiB; larger bodies return 413. File submissions use the separate limits below.

Generic Webhook accepts multipart/form-data with file parts and text fields. Repeated adjuntos[] parts produce one item with binary.adjuntos0, binary.adjuntos1 and text fields under json.body. The file envelope also includes sanitized headers, params and query. A multipart binaryPropertyName: "data" produces data0, data1. Raw binary uses the configured name or data; send Content-Disposition: attachment; filename="report.csv" to name it. Select Raw binary body for content types that would otherwise be treated as legacy JSON/text.

File submissions return 202 with id, status, receiptToken and receiptUrl. Poll the private receipt URL for pending_scan, ready, dispatched, rejected or expired. It reveals no file listing, download or run output. An optional Idempotency-Key deduplicates identical content at that endpoint; changed files, fields, query parameters or business headers with the same key are 409. Multipart boundaries and generated transport/proxy/tracing headers do not change the retry identity. Without a key, requests are separate submissions. Malformed/invalid fields are 400, limits are 413, upload admission limits are 429 with Retry-After, and unavailable Files services are 503. Receiving bytes has an absolute five-minute deadline: a slow or idle body is aborted with 408, releasing its upload slot; start a new upload.

The worker scans before dispatching through the existing outbox. Response workflows can return their captured status, headers and body within the synchronous budget; scanning, queue delay or durable waits or a temporary synchronous-processing error can instead return the accepted receipt. Retry with the same Idempotency-Key to recover it without another run. JSON, Telegram and WhatsApp keep their existing payload and signature paths.

Form pages use /forms/{token}, with definitions/submission at /api/forms/{token}. Member forms require execution permission and same-origin submission with the returned x-form-csrf value. Public forms require the author to enable public access. Test listeners use /api/workflow-file-tests/{token} and expire after 120 seconds and one submission. See workflow tests.

A committed file dispatch remains dispatched during crash recovery, including after the owner loses execution permission. This records the accepted dispatch; the queued run still enforces current authority independently and may fail without executing further steps.

Responses

With durable persistence, workflows without a Response node are accepted into the trigger outbox. The endpoint returns 202 { token, outboxId, status: "accepted" }, or status: "deduplicated" for a repeated provider event. The platform worker picks up committed deliveries through a separate loop every second by default; this does not guarantee that execution or message delivery finishes within a second.

Workflows with a Response node execute inline against a synchronous budget (30s by default):

• If a Response node captured a reply, its status, headers, and body are returned.
• If the run pauses on a durable Wait or approval, the endpoint returns 202 { runId, status: "waiting" } and a worker resumes it later.
• If the budget is exceeded, it degrades to 202 { status: "processing" }.
• Without durable persistence, a workflow with no Response node returns { token, run }.

Next steps