Skip to main content
Execution Fabric webhooks are a production partner preview for admitted personal tenants. Delivery is at least once and may arrive out of order. Your handler must verify the raw body, persist each event_id once, and order events within each run_id by sequence.

Prerequisites

  • A key with both runs:read and runs:write to create or change an endpoint.
  • A public HTTPS endpoint on the default port. Localhost, IP literals, private networks, embedded credentials, and unsafe redirect targets are rejected.
  • A secret manager for the one-time signing_secret.

1. Create an endpoint

Store the returned signing_secret immediately. It is returned only when the endpoint is created.

2. Verify the raw request

Every delivery includes:
Praxa signs this exact string with HMAC-SHA-256:
Create a shared verifier:
lib/praxa-webhook.ts

3. Handle deliveries in your framework

app/api/webhooks/praxa/route.ts
persistOnce must commit a unique event_id before returning 2xx. A duplicate event should return success without repeating its downstream effect.

4. Test the signature locally

5. Verify production delivery

  1. Deploy the HTTPS endpoint and create it in Praxa.
  2. Trigger a disposable task whose event filter matches the endpoint.
  3. Require a valid signature and matching header/body event_id.
  4. Require the handler to persist the event before returning 204.
  5. Send the same signed event twice in a controlled test and require one logical effect.
  6. Send an expired timestamp and a one-byte body change and require 401.
  7. List deliveries with GET /v1/webhook-deliveries and require the expected endpoint and run IDs.
  8. Exercise replay only after correcting a failed endpoint; replay must remain idempotent.
The initial production canary proved one signed raw-body delivery. Retry, dead-letter, and replay behavior still require separate qualification in your integration, so build for them even if your first delivery succeeds.

Troubleshooting

Best practices

  • Persist identity before I/O and state transitions after durable processing.
  • Treat admission, delivery attempt, and cancellation request as non-terminal acknowledgements.
  • Verify signatures against the raw body before parsing webhook JSON.
  • Deduplicate streams and webhooks using stable event or delivery identity.
  • Test disconnect, duplicate, out-of-order, timeout, revocation, and cleanup paths.

Optimize for production

  • Prefer event-driven updates while retaining bounded polling or readback reconciliation.
  • Commit cursors in batches only when that cannot lose acknowledged application work.
  • Keep webhook handlers short: verify, persist, acknowledge, then process asynchronously.
  • Measure admission-to-terminal time, reconnect rate, duplicate rate, delivery latency, and reconciliation backlog.
Optimize only after the correctness and isolation matrix passes. Lower latency or cost is not an improvement if verified outcomes, authority checks, or recovery rates regress.

Cleanup and next steps

  1. Cancel or terminally reconcile disposable runs.
  2. Disable test webhook endpoints and remove their signing secrets.
  3. Delete synthetic inbox, cursor, and delivery records after assertions.
  4. Revoke disposable credentials and keep only redacted lifecycle evidence.
After cleanup, run the shared integration test matrix and record any environment-specific check that remains pending.

Frequently asked questions

What proves this tutorial works?

The minimum observable result is that raw-body signature, persistence, deduplication, replay, and delivery readback pass. A compile, package import, mocked response, or initial admission alone does not prove the complete workflow.

Can a browser, mobile app, or model prompt hold the credential?

No. The trusted runtime owns Praxa keys, OAuth tokens, and webhook secrets; clients receive only bounded application projections.

How should an ambiguous mutation be retried?

Persist the exact logical input and idempotency key before the first attempt. Reconcile through authoritative readback or replay the exact request with that same key before creating new work.

What should we monitor after release?

Monitor admission-to-terminal time, stream reconnects, duplicate events, webhook delivery latency, retries, and reconciliation backlog. Alert on authorization bypass, cross-tenant disclosure, repeated conflicts, or cleanup failure.
Last modified on August 14, 2026