Webhooks push events to a URL you control. Use them for integration with external systems, workflow triggers, and one-way pipelines that don’t need an always-on connection.Documentation Index
Fetch the complete documentation index at: https://docs.myme.so/llms.txt
Use this file to discover all available pages before exploring further.
Registering a webhook
Register viaPOST /webhooks with the target URL, the event kinds to subscribe to, an optional type filter, and an HMAC secret.
Example request and fields
Example request and fields
| Field | Meaning |
|---|---|
url | HTTPS endpoint to POST events to. HTTP allowed for local-development targets. |
events | Array of event names. See event types. Wildcard * accepted. |
type_filter | Optional. Filter item events to these types only. Pattern supports * and parent.*. |
secret | HMAC signing key. Auto-generated if omitted. Returned only in the creation response — retrieve it then, store securely. |
disabled | Optional boolean. Webhook registered but inactive. |
Event types
Webhooks deliver the same event surface as SSE. See the Realtime event catalog for the full list and payload shapes. Each delivery carries:Signature verification
Every delivery is signed with HMAC-SHA256 overtimestamp + "." + raw_body.
Verify:
Delivery semantics
- At-least-once. A successful
2xxresponse is required to mark the delivery complete. Timeouts and non-2xx responses trigger retries. - Best-effort immediate dispatch. Initial delivery is attempted on event publication and typically lands sub-second; if the immediate attempt fails or times out, the durable retry queue takes over. Receivers see no behavioral difference between the two paths — the HMAC signature, headers, and body are byte-identical.
- Durable retry. Deliveries persist in the server’s delivery queue across restarts. No in-memory state.
- Exponential backoff. Default retry schedule: 30s, 2m, 10m, 1h, 6h, 24h, 72h. After the final attempt, the delivery is marked
failedand surfaced viaGET /webhooks/{id}/deliveries. - Idempotency. The
X-Marfa-Delivery-Idheader is unique per delivery attempt;X-Marfa-Event-Idis unique per event. UseX-Marfa-Event-Idto deduplicate across retries.
Managing webhooks
Standard CRUD plus delivery-history endpoints — see the Webhooks API reference for full shapes.Management endpoints (quick reference)
Management endpoints (quick reference)
Scope
Webhooks are tenant-scoped. A non-admin credential can only register and inspect webhooks in its own tenant. Admin credentials see tenant-wide webhooks.Good practice
- Respond 2xx immediately. Accept the event into a local queue, return 200, process asynchronously. Long-running processing during the HTTP response triggers timeouts and retries.
- Verify signatures before trusting payload content. An unverified request body is just an arbitrary HTTP POST to your endpoint.
- Deduplicate on
X-Marfa-Event-Id. At-least-once delivery means the same event id may arrive more than once. - Retry on your end for transient downstream failures. If your consumer fails to process an event after signature verification, don’t return 5xx — Marfa will retry. Instead, return 200 and enqueue locally for your own retry.