Webhook Delivery

Summary

Prepare a receiver for an app-specific delivery path, then prove that events reach it before enabling business effects. Eigenn has no general outbound subscription API, and the current source does not establish a complete automatic delivery flow for the listed marketplace apps.

Capabilities

Current Limit

The public REST API has no create, list, update, or delete endpoint for arbitrary outbound webhook subscriptions. The provider callback endpoints in OpenAPI are for supported providers that call Eigenn. Do not use them as custom delivery targets.

Prerequisites

Before You Start

• Choose the Eigenn team that owns the events.
• Create a dedicated destination for this integration.
• Use a public HTTPS URL.
• Decide which supported event names the destination will accept.
• Make downstream effects safe to repeat.

The Zapier and n8n subscription handlers reject private, loopback, local, and cloud-metadata destinations. For local validation, intercept delivery; do not weaken destination checks to accept localhost.

Concepts

Eigenn automation event delivery allows supported marketplace integrations to trigger external workflows when specific events occur. Catalog event names describe intended integration coverage. They do not prove that an event producer, subscription, or delivery worker is connected. Delivery and identity checks must be confirmed for the specific path.

Workflow

1. Confirm the Delivery Path

Open Apps to inspect the integration's availability and intended events:

• Zapier: invoice.created, invoice.paid, payment.received, customer.updated
• n8n: invoice.created, invoice.paid, payment.received
• Make: invoice.created, invoice.paid, customer.updated

Do not treat installation as a subscription. The source has Zapier and n8n subscription handlers, but a complete setup flow and automatic production of these events from normal business changes are not established. The delivery worker does not handle Make automation events. A generic connection test only checks whether a destination URL exists; it does not prove delivery.

Before continuing, require a controlled event-to-receiver demonstration for your team. If that path is unavailable, keep downstream effects disabled and use documented REST operations for explicit automation. Do not call private browser procedures or provider callbacks to fill the gap.

2. Check the Receiver

When invoked, the Zapier and n8n subscription handlers deliver this envelope:

{
  "type": "invoice.created",
  "organizationId": "00000000-0000-0000-0000-000000000000",
  "occurredAt": "2026-07-11T14:30:00.000Z",
  "data": {}
}

At the receiver:

1. Accept only POST with JSON.
2. Check the top-level fields.
3. Accept only the event names that your workflow supports.
4. Confirm that organizationId matches the expected team.
5. Check the event-specific data before you use it.

The envelope does not promise a universal event ID.

3. Keep the HTTP Response Fast

Persist an accepted event. Return a 2xx response before you start slow downstream work. The Zapier and n8n subscription handlers treat a redirect or any non-2xx response as a failed delivery.

Use a permanent queue for:

• external API calls
• email or messages
• document generation
• finance record updates
• reconciliation that takes a long time

Behavior specification

4. Handle Retries Safely

Each invocation of the Zapier or n8n subscription handler makes up to three delivery attempts with a 10-second timeout per attempt. A worker retry or manual rerun can start another invocation; three is not a lifetime event-delivery limit.

These values apply only to the subscription handlers. The generic webhook action shared by these apps and Make has no retry loop or timeout of its own, follows validated redirects, and sends no signature. See Webhooks for that distinction.

Before you do a write:

• look for a stable business identifier in data
• combine it with the event type when applicable
• enforce uniqueness at the destination
• return the prior successful result for a repeated logical event

Do not use occurredAt alone as a deduplication key.

5. Apply an Explicit Trust Model

Eigenn does not publish a universal outbound webhook signature header or shared signing-secret scheme for marketplace automation deliveries.

Protect the receiver with these steps:

• use the automation platform's access controls when available
• use an unshared, purpose-specific URL
• check organizationId and event contents
• limit the receiver to a narrow action
• reject unexpected fields or values where practical
• keep high-risk customer, cash, and ledger changes behind one more review

A matching organizationId, event name, or X-Canvas-Event header does not authenticate the sender. Do not claim a request came from Eigenn unless the specific integration supplies a verification method that your receiver checks.

Diagrams

Screenshots

Not applicable: this page describes an API or a non-visual workflow rather than an application screen.

Verification

6. Test Failure Modes

Test each of these before you turn on production effects:

1. A valid event returns 2xx.
2. An unsupported event returns 4xx.
3. Malformed JSON returns 4xx.
4. A repeated event does not duplicate the business effect.
5. A receiver timeout produces a retry.
6. A receiver 500 produces a retry.
7. The receiver rejects an organizationId mismatch.
8. A queue outage stops the acknowledgement.

Run the cases with synthetic events, intercepted external requests, and a receiver you control. Examine the receiver and worker logs; do not assume a customer-visible delivery activity log exists. Record the event source, selected handler, attempt counts, and business result without exposing destination secrets. These are acceptance requirements, not a claim that this draft has passed them.

Related

Related Pages

• Webhooks
• Webhooks API Status
• Marketplace Integrations