API Routes & Webhooks

Full Apps can run server code: their own API endpoints on your Informer server, plus webhooks that outside services call into. These two tabs are the operations console for that surface: traffic, errors, latency, and the credentials that guard the doors.

API Routes

Every endpoint the App defines is listed with its method and path, and the tab opens with three KPIs: Calls (30d) with a per-day chart, Endpoints, and Errors (30d).

Every invocation with its status and timing: the two red rows (a 401 and a 400) are exactly what you came to find.

Expand a route to see its recent invocations: method, status code, and timing for each call, plus a daily volume chart for that one route. Each route's URL is one click to copy, handy when testing with curl or wiring the App's endpoint into another system.

Why you'd watch it:

• The Overview tab's error rate fact comes from here. When it spikes, this tab tells you which route is failing and with what status: a wall of 422s usually means an unbound dependency, 500s mean a bug (check Logs for the stack), and 403s mean a caller without access.
• The latency average on Overview also comes from these routes. One slow route drags the whole number; the per-route timings point at the culprit.

Webhooks

Webhooks are endpoints for outside services: a payment processor reporting a charge, source control announcing a push, a chat platform delivering a slash command. They're reachable without an Informer login, so access control happens in the URL itself.

One active token, and the invocation list showing a rejected call (bad signature, 401) next to two accepted events.

Webhook tokens

Access runs on webhook tokens. Each token is an individually revocable credential, embedded in the endpoint URLs you copy from this tab:

• New token creates one; give the URL built from it to one outside service.
• Each token row shows when it was created and its status; Copy token and Revoke token sit on the row.
• Revoking a token kills exactly the URLs built from it. Other services using their own tokens keep working.
• URLs without a token are rejected outright.

The discipline that pays off: one token per outside service. When you stop using a service (or its URL leaks into a log somewhere), revoke that one token and nothing else is disturbed.

Rotating the secret

Rotate Webhook Secret is the bigger hammer: it invalidates every webhook URL at once. The confirmation says exactly that. Reach for it when you can't tell what leaked, or during an ownership change; then re-issue URLs to each service from fresh tokens.

Example: wiring up a payment processor

1. Open Webhooks, click New token, copy the endpoint URL for the App's payments webhook.
2. Paste it into the processor's webhook settings.
3. Watch the route's invocations appear here as test events arrive; 200s mean the App accepted them.

Troubleshooting

• The outside service reports failures / events stopped arriving. Check the webhook's recent invocations here. Nothing arriving at all usually means a revoked token or rotated secret: the service is calling a dead URL. Re-issue from a fresh token.
• Invocations arrive but error. The handler is rejecting them; common causes are a wrong signing secret in Environment (signature verification fails, often a 401) or a bug surfaced in Logs.
• You inherited an App and don't know who has webhook URLs. That's the rotate-secret scenario: invalidate everything, then re-issue deliberately, one token per service.

Also available through the REST API

Everything on this page is built on Informer's public REST API, the same one the product uses, so your scripts and integrations can do it too. Developer reference: Server Routes and Webhooks.