HMAC-authenticated inbound fires and schedule chains
Triggers & webhooks
Triggers & webhooks, at a glance
HMAC-authenticated inbound fires and schedule chains
POST /v1/triggers/webhook/{id}- 01Receiveraw body + timestamp
- 02Verifyconstant-time HMAC
- 03Dedupepayload identity
- 04Fireschedule run admitted
Add a trigger with POST /v1/schedules/{id}/triggers and triggers:write. A webhook trigger returns its public webhook_url and its HMAC signing secret as webhook_secret only on create (and an exact bounded idempotency replay); save it in a secrets manager. There is no signing_secret field, and GET/list returns no secret at all. Triggers are attached to a schedule, so the create route is POST /v1/schedules/{id}/triggers; there is no top-level POST /v1/triggers. The /v1/triggers prefix carries only the unauthenticated ingress route POST /v1/triggers/webhook/{webhook_id} and a health probe. A chain trigger starts the target when another schedule completes, fails, or reaches either outcome, with a maximum chain depth of five.
Webhook ingress uses no Coasty API key. Compute HMAC-SHA256 over<unix_ts>.<raw_body> with the create-time secret and send exactly one of Coasty-Signature or X-Coasty-Signature as t=<unix_ts>,v1=<hex_digest>. The server verifies the raw bytes, timestamp window, body cap, per-webhook rate limit, and identical-body deduplication before durable dispatch. Read effective replay, dedup, body-size, rate, and wallet-gate values from GET /v1/models under pricing.schedules.