Production Deployment
Move from local development to a production-grade webhook pipeline. This guide covers what to change, check, and harden before going live.
1. Disable dev mode on your endpoint
Dev mode routes events to your local CLI agent instead of your production server. Before going live, make sure it's off.
- 1Go to Endpoints in the sidebar
- 2Click your endpoint → Edit
- 3Toggle Dev mode off
- 4Set the Destination URL to your production server (e.g.
https://api.example.com/webhooks) - 5Save
Once dev mode is off, events are forwarded directly to your destination URL. Make sure your production server is running and reachable before disabling it.
2. Set your destination URL
Use your production HTTPS endpoint. FirmHook requires a valid, publicly reachable URL — localhost or private IP addresses are not accessible from FirmHook's servers in production mode.
If your server is behind a load balancer, use the load balancer's public URL.
3. Configure outbound authentication
FirmHook can authenticate its requests to your server so you can verify that incoming webhooks are genuinely from FirmHook and not from an external attacker.
In Endpoints → Edit → Outbound auth, choose one of:
| Method | Description |
|---|---|
| HMAC signature | FirmHook signs each request with a secret. Verify the X-FirmHook-Signature header on your server. |
| Bearer token | FirmHook sends Authorization: Bearer <token> with every request. |
| Basic auth | FirmHook sends a username and password in the Authorization header. |
| Custom header | FirmHook adds any header you specify with a value you set. |
HMAC is recommended for production — it proves the payload has not been tampered with in transit.
4. Set retry limits
Review your Max retries setting (default 5). For production:
- High-value events (payments, orders) — keep at 5 to maximise delivery success
- Low-priority events (analytics, logs) — lower to 2–3 to reduce load on your server during outages
- Idempotent endpoints — retries are safe; keep default or increase
- Non-idempotent endpoints — consider lowering retries or adding idempotency handling on your server
5. Set a timeout
The default timeout is 30 seconds. If your endpoint is expected to respond quickly, lower the timeout to prevent slow responses from blocking the delivery queue:
In Endpoints → Edit, set Timeout to a value appropriate for your server's expected response time (e.g. 5–10 seconds for fast APIs).
6. Enable Slack notifications
Get alerted immediately when deliveries fail rather than waiting to check the dashboard.
See Slack Notifications to connect your workspace.
7. Rotate your API key
If you used a development API key during testing, create a new one for production:
- 1Go to Settings → API Keys
- 2Click Create API Key and label it clearly (e.g.
Stripe Production) - 3Update the external service with the new key
- 4Delete or deactivate the old key
API keys are shown only once at creation. Store them securely (e.g. in your secrets manager, not in source code).
8. Monitor your events
Once live, use the Events dashboard to track delivery health:
- Watch for
partialordeadevents — these indicate delivery failures - Use Replay to re-deliver any failed event after fixing the underlying issue
- Check the event timeline for AI-generated explanations on any failures
What's next?
- Understanding Retries — retry behaviour and backoff schedule
- AI Error Explanations — interpret failure messages in the dashboard
- Slack Notifications — stay informed when deliveries fail