Inbound events
See accepted partner events, duplicates, and retry workflow start.
Inbound events are HMAC-signed POSTs from partners. Portal Webhooks → Events is the accept log — not the lead payload.
Open WebhooksThe default tab. Each row is one accepted POST: partner, event type, external id, correlation id, status, and start status. Duplicate external ids stay on the log and do not start a second workflow.
What an event is
Connect verifies the signature, persists partner_webhook_event, then retryably starts the catalog workflow bound to that eventType (optional partnerId). Lead JSON stays on the event row. The workflow input is ids only.
| Status | Meaning |
|---|---|
| Accepted | Signature verified; row stored |
| Duplicate | Same (partnerId, externalId) — HTTP 200, zero extra runs |
| Pending (start) | Accept succeeded; workflow start not yet confirmed |
| Failed (start) | Start exhausted retries (ten attempts). Use Retry start |
Retry start
If Temporal was down after persist, the row stays Pending/Failed with startAttempts. Operators retry from Events (POST /api/v1/ops/webhooks/inbound/{id}/retry). That resets the ten-attempt cap.
How it looks in Portal
Webhooks → Events. Search by partner, event type, external id, or correlation id. Status uses the same chips as Runs.
If this fails
| Symptom | Cause |
|---|---|
| 401 / invalid signature | Wrong secret, or you hashed a parsed JSON string instead of the raw body |
| 200 Duplicate, no new run | Same externalId for that app — expected |
| Event Accepted, no run | Start still Pending/Failed — Retry start |
| Event missing | App id in the URL does not match a registered app, and no fallback secret |
Next: Register an app · Sign requests