Tifybe Documentation

Tifybe sits between webhook providers (Stripe, GitHub, Shopify, your own SaaS) and your server. Providers send events to a unique Tifybe receiver URL; Tifybe stores each event durably (encrypted at rest), then delivers it to your target URL with automatic retries, exponential backoff, fallback URLs and a Dead Letter Queue. If your server is down for an hour — or a day — you lose nothing.

Three concepts cover the entire product:

1. Create an endpoint. Go to Endpoints → New Endpoint. Enter a name and your real target URL (your Express/Django/Next.js handler). You get back a receiver URL and a secret key.
2. Save the secret key. It is shown exactly once. You need it to sign webhooks you send to Tifybe yourself (not needed when a provider like Stripe posts to you).
3. Point your provider at the receiver URL:

   https://api.tifybe.com/webhook/<YOUR_RECEIVER_PATH>

4. Press Test. Every endpoint has a Test button that pushes a signed event through the full pipeline. Watch it arrive under Webhooks in real time.

Give the receiver URL to Stripe, GitHub, Shopify or any provider exactly where they ask for a "webhook URL". Tifybe accepts the event, encrypts the payload, answers 200 immediately, and takes over delivery to your server.

Each endpoint has a signature mode that says who is allowed to send to it:

• Provider signature — paste your provider's signing secret (e.g. Stripe's whsec_…) and Tifybe verifies each event with the provider's own scheme. Supported natively: Stripe (Stripe-Signature), GitHub (X-Hub-Signature-256), Shopify (X-Shopify-Hmac-Sha256) and Standard Webhooks / Svix (used by Polar, Clerk and many others). The scheme is auto-detected from the request headers.
• Tifybe HMAC — for senders you control; sign with your endpoint secret as shown in the section below.
• None — accept unsigned requests. Your receiver URL contains 128 bits of randomness and duplicates are suppressed, so this is a reasonable default for providers without signatures — but prefer provider mode when a signature exists.

Provider events are deduplicated automatically: Tifybe recognizes Stripe-Event-Id and X-GitHub-Delivery natively — a Stripe retry of the same event will never hit your server twice.

If you are a SaaS delivering webhooks to your customers, push events into Tifybe and let it handle retries, backoff and the DLQ. Sign each request with your endpoint's secret key:

const crypto = require('crypto');

const payload = JSON.stringify({ user_id: 123, action: "payment_success" });
const timestamp = Math.floor(Date.now() / 1000).toString();
const secret = process.env.TIFYBE_ENDPOINT_SECRET;

// 1. Sign: HMAC-SHA256 over "{timestamp}.{payload}"
const signature = crypto
  .createHmac('sha256', secret)
  .update(timestamp + "." + payload)
  .digest('hex');

// 2. Send to your Tifybe receiver URL
await fetch('https://api.tifybe.com/webhook/YOUR_RECEIVER_PATH', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Tifybe-Timestamp': timestamp,
    'X-Tifybe-Signature': signature,
    'X-Idempotency-Key': crypto.randomUUID(),
  },
  body: payload,
});

This section describes Tifybe's own scheme— used when an endpoint's signature mode is Tifybe HMAC(senders you control) and for signatures Tifybe adds to outbound deliveries. Provider-mode endpoints are verified with the provider's scheme instead (see the section above). The scheme is deliberately boring and standard:

1. Take the current Unix time in seconds → timestamp.
2. Concatenate {timestamp}.{raw request body} — a literal dot between them, body exactly as sent (no re-serialization).
3. Compute HMAC-SHA256 over that string with your endpoint secret key, hex-encoded.
4. Send it as X-Tifybe-Signature together with X-Tifybe-Timestamp.

Inbound — what you send to a receiver URL:

* Signature headers are required unless signature verification is disabled for your deployment.

Outbound — what Tifybe sends to your target URL:

Tifybe picks the deduplication key for each incoming event in this order:

1. Stripe-Event-Id header, if present
2. X-GitHub-Delivery header, if present
3. X-Idempotency-Key header, if present
4. Otherwise: an HMAC hash of the payload, scoped to the endpoint

A repeated key gets a 200 response (so providers stop retrying) but is recorded with status duplicate and never delivered twice. Duplicate records are kept for 7 days.

A delivery counts as failed when your server returns a non-2xx, times out, or refuses the connection. Failed deliveries are retried on this exact schedule:

Each plan sets the total number of delivery attempts (the first delivery plus automatic retries): up to 3 on Free, 10 on Pro, 20 on Enterprise. On Pro and above you can also set a lower per-endpoint override for endpoints where staleness matters more than persistence.

For a delivery to count as successful, your target URL must:

• Return any 2xx status — 200, 202,204 all count. 3xx redirects are not followed; 4xx/5xx count as failures.
• Respond within the timeout — connection must open within 5 seconds; the response timeout is configurable per endpoint (1–60 s). Do heavy work after responding: acknowledge first, process async.
• Be idempotent — retries mean the same event can arrive more than once. Use X-Tifybe-Trace-Id (or your own event IDs) to deduplicate on your side.

Responses are logged per attempt (status code, duration, first 1 KB of the body) — see any webhook's detail page for the full timeline.

Both are configured per endpoint (endpoint form → Filters & transform) and run inside Tifybe — your server only ever sees the events you actually want, in the shape you want.

Filter rules decide whether an event is delivered. Each rule tests a payload field (dot-path like data.amount, array indices like items.0.id) or a request header via the headers. prefix. Operators: equals, not_equals, contains, starts_with, ends_with, gt, lt, exists, not_exists. Combine rules with all (AND) or any (OR). Non-matching events are stored with status filtered— inspectable in the dashboard, never delivered, never retried, so they don't burn delivery attempts on your target. Free plans get 3 rules per endpoint, paid plans 10.

Payload transformations (Pro+) rewrite the payload beforedelivery with a JavaScript function — rename fields, drop noise, reshape a provider's format into your API's:

function transform(event) {
  // event.payload = parsed JSON body
  // event.headers = original request headers
  return {
    kind: event.payload.type,
    amount_cents: event.payload.data.amount,
    source: event.headers["User-Agent"],
  };
}

• The return value becomes the delivered body — objects are JSON-encoded, strings sent as-is.
• Runs in a sandbox (no network, no filesystem) with a 100 ms execution limit and a 10 KB code limit.
• Applied on every attempt, including automatic retries and manual DLQ replays.

Fallback URL (Pro+): when the primary target exhausts all retries, Tifybe makes one final attempt to your fallback URL — e.g. a backup Lambda or a logging service. If it succeeds, the webhook is marked delivered_fallback; otherwise it goes to the DLQ.

Circuit breaker: if an endpoint accumulates 50 consecutive dead webhooks, Tifybe automatically pauses it and emails you. This protects your monthly quota from burning while your server is down. Fix the target, flip the endpoint back to active, then bulk-retry from the DLQ. Any successful delivery resets the counter.

Webhooks that exhaust every attempt land in the Dead Letter Queue with their full payload and delivery history intact. Nothing is deleted. From there you can:

• Retry one — re-queues it through the normal pipeline.
• Retry all — bulk replay after an outage (Pro+; Free has a cooldown).
• Delete — permanently removes the webhook and its history.

You'll also get an email alert based on your failure threshold — e.g. "alert me after 5 consecutive failures".

Quota-exceeded events are still recorded so you can see exactly what you missed — upgrade and the next events flow immediately.

• Encryption at rest: every payload and endpoint secret is encrypted with AES-256-GCM before touching the database.
• Transport: all traffic is TLS. Receiver paths are 64-char random hex — unguessable.
• Authentication: dashboard sessions use Clerk (JWT). Server-to-server calls use API keys (tfy_…) stored only as bcrypt hashes.
• Replay protection: 5-minute timestamp window + constant-time signature comparison.
• Data lifecycle: logs expire per plan retention; account deletion soft-deletes immediately and purges after 30 days.

The open-source Tifybe CLI opens a secure WebSocket tunnel so webhooks reach your localhost during development — no port forwarding, no third-party tunnels.

Checkout and invoicing are handled by Polar (our merchant of record). Cancel anytime — access lasts until the period ends. Manage billing →

Still stuck? Every webhook's detail page shows the exact request we received and every delivery attempt with response codes and bodies — start there, then write to us with the trace ID.