Webhooks
Learn how Eigenn uses provider callbacks and app-specific automation deliveries, and where no universal webhook contract exists.
Summary
Eigenn separates two webhook directions:
- Supported providers call Eigenn to report changes.
- Outbound automation handlers can send selected events to configured destinations, subject to the availability limits below.
These are separate contracts. The public API has no general endpoints to create, list, update, or delete arbitrary outbound webhook subscriptions.
Capabilities
Public API Availability
The generated WebhooksApi in Eigenn SDKs wraps provider callback endpoints from the OpenAPI document. It is not a client that manages outbound subscriptions.
Eigenn does not document a general subscription API as part of public API v1. Marketplace catalog entries do not replace that API or prove that a complete event-delivery path is enabled.
Prerequisites
To use provider callback endpoints, you must have an active integration with a supported external service, following the authentication and payload requirements for that provider. For outbound automation, require a confirmed event source, team-specific subscription, running delivery worker, and controlled receiver test. Installation alone is not sufficient.
Concepts
Provider Callbacks
The OpenAPI document includes callback endpoints for supported services such as Stripe, inbox ingestion, WhatsApp, Polar, and Storecove e-invoicing. Eigenn intends each of these endpoints for its own first-party connection.
They are not general ingestion endpoints for custom applications. Authentication and verification are different for each provider. Some callbacks use provider signatures or connection-specific secrets instead of an Eigenn bearer token.
Do not send custom payloads to the provider callback endpoints. Send them only when the relevant integration setup tells you to do so.
Automation Deliveries
The App Marketplace includes automation connections for Zapier, n8n, and Make.
| App | Events named in the catalog |
|---|---|
| Zapier | invoice.created, invoice.paid, payment.received, customer.updated |
| n8n | invoice.created, invoice.paid, payment.received |
| Make | invoice.created, invoice.paid, customer.updated |
The current source includes Zapier and n8n subscription-delivery handlers, but does not establish a complete customer setup flow or a producer that sends ordinary invoice/customer changes to that delivery chain. Make has a catalog and a generic delivery action, but no Make branch in the integration-event delivery worker. Treat automatic delivery as unavailable until an end-to-end check confirms it for your deployment.
A connection test for these generic webhook actions only checks that a destination URL is present; it does not send an event. The settings panel does not supply the subscription editor or signed test promised by some app descriptions.
The Zapier and n8n subscription handlers use this shared payload shape when invoked:
{
"type": "invoice.paid",
"organizationId": "00000000-0000-0000-0000-000000000000",
"occurredAt": "2026-07-11T14:30:00.000Z",
"data": {}
}The contents of data depend on the event. The shared envelope does not guarantee a universal event ID.
Signature and Deduplication Boundaries
Eigenn does not now publish a universal outbound signature header or signing-secret contract for marketplace deliveries. Do not assume that an X-Canvas-Signature header or an equivalent header is present.
organizationId and X-Canvas-Event are not proof of origin. Until your integration supplies an authenticated delivery mechanism:
- publish only a purpose-built endpoint
- check the payload shape and the permitted event names
- restrict the actions that the endpoint can trigger
- use provider or automation-platform access controls where available
- make the downstream work safe to repeat
The shared envelope has no guaranteed event ID. Choose a business-level idempotency key from stable fields in the event data when the destination does a sensitive write. Do not deduplicate only by delivery time.
Workflow
Receiver Pattern
- Check the request method and the JSON content type.
- Reject the event names that your workflow does not support.
- Check organizationId against the intended Eigenn team.
- Persist the accepted payload before you start slow work.
- Return a 2xx response.
- Process the event from a permanent queue.
- Record enough business context to detect repeated effects.
Behavior specification
Delivery Behavior
For each invocation of the Zapier and n8n subscription handlers:
- a destination must be an external HTTP or HTTPS address
- Eigenn rejects private, loopback, local, and cloud-metadata destinations
- any 2xx response counts as successful delivery
- Eigenn retries network failures and non-2xx responses
- each request has a 10-second timeout
- the handler stops after three total tries; this is not a lifetime limit across worker retries or manual reruns
- redirects are treated as failed responses, not followed
Zapier retries after about 500 milliseconds and then 1 second. n8n retries after about 1 second and then 2 seconds. These values describe the subscription handlers, not a platform-wide guarantee. The separate generic action shared by Zapier, n8n, and Make sends the supplied event and an X-Canvas-Event header. It computes no signature, adds no retry loop or request timeout of its own, and follows up to three redirects while checking each destination. Do not apply the subscription-handler policy to that action.
Diagrams
Rendering diagram…
Screenshots
Not applicable: this page describes an API or a non-visual workflow rather than an application screen.
Verification
Run these checks with isolated synthetic data and intercepted delivery. No outbound runtime verification is claimed here.
- Trace one supported business event to a saved team subscription and a receiver request. Record a missing producer, subscription flow, or worker as a blocker; an app badge is not a pass.
- Invoke the confirmed subscription handler with a controlled destination. Check the envelope, team ID, and event-specific data.
- Return 2xx, then separately exercise redirects, non-2xx responses, and timeouts. Count attempts per handler invocation and distinguish later worker retries.
- Check that private/local destinations are refused and that wrong-team or malformed payloads cannot cause a receiver-side effect.
- Repeat a logical event and confirm one business effect. Do not infer authenticated origin from payload fields or the event header.