Reliability

Guarantees built into the API

These hold for every purchase, whatever the network is doing:

Guarantee	How
No purchase is made twice	Your reference is an idempotency key. See Idempotency.
Every purchase reaches a final state by a known time	Each purchase carries resolve_by. See Lifecycle.
You pay only for confirmed credits	The price is held while pending and charged only on successful.
You hear about every final state	Webhooks are retried, and every purchase can be looked up. See Webhooks.
Your records can always be checked	Closed daily statements never change. See Reconciliation.

Availability, latency and support commitments

Availability and support commitments are set in each partner’s agreement with Aura. These docs do not publish an uptime percentage or a delivery time, because delivery depends on each network. Instead, the API reports what is happening now:

• each network’s live status;
• recent_delivery, the measured time to confirmation over the last hour;
• resolve_by on every purchase, the latest time it will be final.

Your technical contact can share delivery measurements for the networks you plan to use during an evaluation.

Building an integration that copes

• Time out and retry. Give purchase requests a timeout, then retry with the same reference and backoff.
• Retry only what can succeed. Use error.retryable. Never retry other 4xx errors unchanged.
• Do not block your customer on confirmation. Accept the order, tell the customer the data is on its way, and update them when the webhook arrives.
• Route around a network that is down. On network_unavailable, pause that network and offer another if you can.
• Watch for the impossible. A purchase still pending after its resolve_by should never happen. If you see one, report it.
• Reconcile every day. See the daily routine.