Webhooks API Status
Separate provider callback endpoints from the outbound subscription API that public v1 does not include now.
Summary
Eigenn public OpenAPI v1 contains provider callback endpoints. It does not contain general outbound subscription management.
Capabilities
No Public Subscription CRUD
Public v1 does not document:
- POST /webhooks to create a subscription
- GET /webhooks to list subscriptions
PATCH /webhooks/{id}DELETE /webhooks/{id}
Public v1 also does not publish a universal outbound event catalog or a signature header. It does not publish a method to exchange a secret that signs deliveries, a delivery ID, or a retry policy.
Prerequisites
For provider callbacks, complete the supported provider connection and its verification setup. For outbound automation, first confirm a working event source, saved destination subscription, and delivery worker for your team. An app listing or connected status alone does not prove that delivery is available.
Concepts
Provider Callback Endpoints
Provider callbacks use canonical /webhook paths; a plural /webhooks alias is also defined. Use the exact path supplied by the provider setup; do not depend on the alias in every deployment. Supported connections include:
- Inbox ingestion
- Polar
- WhatsApp verification and events
- Stripe
- Storecove e-invoicing
- Conduitt bridge, Plain support, and Resend delivery events
Each endpoint is a destination for its provider. They can use provider-specific verification. The normal customer API bearer scheme does not protect them.
Do not call them to publish a custom event or to register a delivery endpoint.
Generated SDK Boundary
Generated SDKs include a WebhooksApi because OpenAPI tags the provider callback operations as webhooks.
That generated class is not an outbound webhook-management client. We recommend that most API consumers do not call the provider callback methods directly.
Workflow
Check Automation Availability
Zapier, n8n, and Make have catalog entries, but they do not establish an end-to-end subscription service. The current source contains Zapier and n8n subscription-delivery handlers. It does not establish that ordinary invoice or customer changes enqueue those deliveries, or expose a complete subscription setup flow. The delivery worker has no Make automation branch.
Before relying on any of these integrations, obtain a successful event-to-receiver check for your deployment. Do not interpret a catalog event name, a saved destination URL, or a connection check as that evidence. Until delivery is confirmed, use the documented REST operations for explicit reads or writes from your automation.
See Webhooks for event names and the boundaries of the available delivery handlers.
Behavior specification
Stripe Connect callback compatibility
The Eigenn API accepts Stripe Connect callbacks at POST /webhooks/stripe as well as the versioned provider route. The compatibility URL forwards the original request body and Stripe signature to the same verification handler without a redirect. Missing or invalid signatures are rejected. The alias does not expose other unversioned webhook routes or accept GET requests.
Keep the exact callback URL and signing secret supplied by the connection setup. This API callback handles Connect events; it is separate from the web application's subscription billing callback. A successful request does not prove that an earlier failed event was replayed.
Legacy Event Names
Legacy documentation listed names such as invoice.updated, payment.succeeded, transaction.enriched, and workflow.completed as a general event catalog. Public OpenAPI v1 does not define that catalog.
Use only the event names that the selected marketplace app shows. Do not build a generic subscriber for undocumented names.
Security
Marketplace automation does not publish a universal Eigenn signature scheme. The delivery code reviewed here does not compute a signature. Payload fields, including organizationId, are caller-controlled and do not authenticate the sender. Apply these controls:
- Use a purpose-specific destination.
- Confirm organizationId and the event data.
- Accept only the expected events.
- Make the effects idempotent.
- Examine high-risk writes more carefully.
Diagrams
Rendering diagram…
Screenshots
Not applicable: this page describes an API or a non-visual workflow rather than an application screen.
Verification
These checks remain pending for outbound automation; the copy review is not delivery evidence.
- Use an isolated provider fixture to check the configured callback path and its provider-specific verification. An Eigenn API key must not substitute for a required provider signature.
- Confirm your client does not call a nonexistent public subscription-management operation.
- For an outbound integration, require a recorded event source, saved subscription, and intercepted receiver delivery. A catalog listing is insufficient; record a missing connection in this chain as a gap.
- Check receiver validation, duplicate handling, and wrong-team rejection independently of provider callback acceptance.