HookFork /

SETUP AND RECEIVER CONTRACT

Connect applications safely

  1. Ask the operator for an owner invitation.
  2. Create a project for each application.
  3. Create a source with an exact Stripe account, mode, snapshot format, and supported API version.
  4. Supply a restricted read key and webhook secret through the write-only fields.
  5. Verify the account, then approve exact resource claims.
  6. Create a public HTTPS destination and store its secret in the receiver's vault.
  7. Install a receiver that checks the HookFork signature and rejects invalid signatures.
  8. Run the destination probe, then create exact event routes.
  9. Send a real signed source verification event through an approved sandbox setup.
  10. Activate the source after the source and receiver checks pass.

Live endpoint changes require a separate exact migration plan. Keep direct receipt active until receiver idempotency and rollback checks pass.

Subscriptions are part of the first release

Ownership comes from complete, version-aware resource relationships. Renewals do not require a prior Checkout event. Historical invoices must not inherit current Subscription items after a product change.

Applications retain payment, tax, subscription-state, and entitlement decisions. HookFork neither charges customers nor manages those decisions.

Source acknowledgment

A successful response means durable receipt, not destination success. In particular, a destination failure cannot delay Stripe invoice finalization through HookFork's acknowledgment of invoice.created.

Delivery verification

Verify HMAC-SHA256 over the timestamp, a period, and the exact request bytes. Decode the destination secret after its hfsec_ prefix as base64url. Reject timestamps outside 300 seconds.

Use the provider event ID inside the authenticated JSON for deduplication. Use application business keys across related events. Delivery is at least once and has no order guarantee.

Agent access

Use a project-scoped bearer credential. Create and replay requests require Idempotency-Key. Configuration changes require expected_revision equal to the record's current version. The separate revision field identifies immutable URL or route content.

Use the exact User-Agent OpenAI File Downloader, XaiImageApiFetch/1.0. See the OpenAPI contract for request schemas.

Supported snapshot baseline

Payload API version: 2026-08-26.dahlia. Routes select exact subsets, never wildcards.

Additional receiver event families need explicit adapter support and evidence before migration. Unsupported or unprovable events remain held for owner review.