Operate
Incidents and what to expect from us
What our unavailability does to your deposit flow, what the availability commitment does and does not cover, and what to have in hand when you contact us.
What our outage does to you
It stops you crediting. That is the design, and it is the trade you accepted when you put a gate in front of the credit path.
We return 5xx with no verdict. Your client applies HOLD. Deposits queue. Nothing is credited that we did not clear, and nothing is lost — the decisions simply have not been made yet.
There is no mode in which our unavailability results in a CREDIT. If you find one, that is a bug in your client, and it is worth more of your attention than the outage was.
What the availability commitment covers
Availability. Only availability.
The service level attaches to whether the API answers, not to whether any particular judgement was right. We do not commit to a specific amount of advance notice on any enforcement event, on any issuer, ever — the interval is a by-product of the issuer’s governance structure, not a capability we supply, and an issuer can change how it executes at any time without telling anyone.
What we do commit to is that when there is a signal you get it as soon as we have it, and that when we cannot see, we say so rather than returning a quiet empty result. That is what coverage_health is for.
What we will tell you, and where
| Channel | Carries |
|---|---|
| Status page | Current availability and open incidents. |
coverage.health_changed webhook | Blind spots and recoveries in the scope that applies to your account. |
GET /v1/coverage | The same, on demand, per authority. |
| Post-incident write-up | What broke, what the effect on decisions was, and what changed. |
Coverage degradation and service unavailability are separate things and are reported separately. We can be fully available and unable to see; the API will say so on every response rather than letting the two collapse into one green light.
What to have ready when you contact us
| Identifier | Where it comes from |
|---|---|
request_id | Present on every Problem response body. |
decision_id | On any 200 from the decision endpoint. |
Foreshock-Delivery-Id | Header on a webhook delivery. |
event_id | Body of a webhook delivery. |
| Timestamps in UTC | Yours and ours, so the two timelines can be aligned. |
Do not send us the address book, screenshots of user data, or raw deposit records. The references above are enough for us to find the record on our side, and they are the only thing we ask for.
Your own incident drill
Two failures are worth rehearsing before they happen.
We are down and you are holding. Who decides to keep holding? Who talks to the affected users? What is the queue depth at which you page someone senior? The answer must not be “we will turn the gate off”, because the gate being off is the state in which the losses actually occur.
Your webhook receiver was down and you did not notice. Deliveries retry for up to 24 hours and then dead-letter with an alert on your account. Rehearse the catch-up: run the exposure cursor loop from your last persisted cursor, reconcile, and confirm your local match set matches the feed. A receiver that has been quiet is indistinguishable from a world that has been quiet, unless you go and check.
What we will never do
Move funds. Freeze anything. Act on your behalf. There is no capability in the product that transfers value, and there is no key in the system that can. During an incident, the set of actions available to us is the same as it is on a normal day: tell you what we can see, and tell you what we cannot.