Retries & Delivery
Mitte processes webhook deliveries asynchronously. When a provider sends a webhook to your Mitte endpoint, the sender receives an immediate 202 Accepted — Mitte then forwards the payload to your target URL in the background.
Delivery Flow
Ingestion
Your webhook provider sends a POST request to https://mitte.run/api/v1/h/mt_xxxxxxxxxx. Mitte validates rate limits, checks payload size, and returns 202 Accepted immediately.
Queuing
The webhook is placed in a background job queue (BullMQ). The number of retry attempts depends on your plan.
Forwarding
Mitte forwards the request to your target URL with the original headers (minus hop-by-hop headers) plus Mitte-specific headers (X-Mitte-Signature, X-Mitte-Attempt, etc.).
Logging
The full delivery — request headers, body, response status, response body, timing, and retry metadata — is logged and available in real-time via the dashboard.
Retry Policy
| Plan | Max Attempts | Backoff Strategy |
|---|---|---|
| Free | 1 (no retry) | — |
| Pro | 5 | Exponential backoff |
Exponential Backoff (Pro)
Pro plan retries use exponential backoff with a base delay of 5 seconds:
| Attempt | Delay |
|---|---|
| 1st (initial) | Immediate |
| 2nd (1st retry) | ~5 seconds |
| 3rd (2nd retry) | ~10 seconds |
| 4th (3rd retry) | ~20 seconds |
| 5th (4th retry) | ~40 seconds |
A delivery is considered failed if:
- The target URL returns an HTTP status code ≥ 400
- The connection times out
- DNS resolution fails
- The target URL is unreachable
Header Forwarding
Mitte forwards original provider headers to your target URL, excluding hop-by-hop and proxy headers:
host, connection, proxy-connection, transfer-encoding, keep-alive, proxy-authenticate, proxy-authorization, te, trailer, upgrade, cf-ray, cf-visitor, cf-connecting-ip, x-forwarded-for, x-forwarded-proto, x-forwarded-host
Mitte-Specific Headers
These headers are added by Mitte to every delivery:
| Header | Description |
|---|---|
X-Mitte-Attempt | Current attempt number (1, 2, 3, etc.). |
X-Mitte-Signature | HMAC-SHA256 signature (only if signing secret is set). See Webhook Signing. |
X-Mitte-Transform | applied or failed (only if a transform rule is configured). See AI Transforms. |
Source Detection
Mitte automatically identifies the webhook provider from request headers. 34+ providers are detected, including:
| Category | Providers |
|---|---|
| Payments | Stripe, Shopify, Paddle, Lemon Squeezy, PayPal, Square |
| Git & CI/CD | GitHub, GitLab, Bitbucket |
| Communication | Slack, Discord, Twilio, SendGrid, Resend, Mailgun |
| DevTools | Linear, Jira, Vercel, Netlify, Supabase, PagerDuty |
| Auth | Clerk, Auth0 |
| Cloud | AWS SNS, Google Cloud, Azure Event Grid |
| Other | Figma, Notion, Calendly, HubSpot, Zoom, Intercom, Typeform, Svix |
The detected source is displayed as a badge in the log inspector. Detection is based on header fingerprinting (e.g., stripe-signature for Stripe, x-github-event for GitHub).
Endpoint Down Detection
Mitte tracks consecutive delivery failures per endpoint. When an endpoint reaches 5 consecutive failures, you'll receive an ENDPOINT_DOWN notification (in-app and optionally via email or outbound webhook).
The failure counter resets when:
- A delivery succeeds
- 1 hour passes with no activity
Test Webhooks
You can send test events to any endpoint via the dashboard or MCP:
- Dashboard: Open the endpoint detail page → click Send Test → enter a custom JSON payload or use the default.
- MCP: Use the
send_testtool with an optional custom payload.
Test webhooks are marked with a test badge in the logs and include the x-mitte-test: true header. Test events always use 1 attempt (no retry), regardless of plan.
Log Retention
Delivery logs are retained based on your plan:
| Plan | Retention Period |
|---|---|
| Free | 3 days |
| Pro | 14 days |
Logs are automatically cleaned up every hour in batches. The retention timer starts when the log is created (at delivery time).