Outbound webhooks
Inbound machine endpoints
Besides the v1 API, a small set of machine-facing endpoints already exists. They are listed here for completeness and for operators wiring deployments — none of them are for third-party use.
| Endpoint | Caller | Auth |
|---|---|---|
POST /api/aml/webhooks/{provider} | The AML screening provider | HMAC signature, verified per provider adapter |
/api/bills/inbound/poll | The bills-inbox scheduler | Bearer secret (environment-configured) |
/api/cron/* | The deployment's cron | Bearer secret (environment-configured) |
GET /api/health | Load balancers, uptime checks | None — liveness only, touches nothing |
POST /api/waitlist | The marketing site's form | None — honeypot + validation |
The AML webhook, in detail
Monitoring alerts and check results arrive from the screening provider signed. The route verifies the signature against the shared webhook secret before anything is processed — unsigned or mis-signed posts are rejected, and events are idempotent on the provider’s event id, so a redelivered event never applies twice. Unknown subject references answer 200 deliberately: providers send test pings.
POST /api/aml/webhooks/sumsub
X-Signature: <provider HMAC>
{ "event_id": "…", "type": "monitoring.alert", "subject_ref": "…", … }The health probe
GET /api/health answers 200 with no authentication and no database touch — it exists for load balancers and uptime monitors, and it is the only endpoint exempt from a staging deployment’s access gate.