Model A - direct dispatch
One order, one result. You decide when a call happens. This is the whole API for most integrations, and the only model you need to read about to start.
You submit a call order - call this person about this claim. A Pace voice agent places the call, identifies the person, discusses the claim inside a negotiation corridor you define, and returns a structured result you can branch on. Results reach you by webhook, or you pull them from an event feed.
The platform enforces its own rules and cannot be overridden: statutory calling hours, do-not-call entries, and AI disclosure in the conversation. Your configuration can narrow those rules; it can never widen them.
Model A - direct dispatch
One order, one result. You decide when a call happens. This is the whole API for most integrations, and the only model you need to read about to start.
Model B - event-driven escalation
You emit signals - business facts such as claim handed over or payment received. A versioned sequence starts an enrollment that works down an escalation ladder and stops the moment payment arrives.
The agent records what the debtor proposes. It never concludes an agreement.
An instalment plan discussed on the phone comes back to you as
installment_plan_requested - the binding arrangement is one you make afterwards,
in writing. There is deliberately no configuration value that changes this.
Every call opens with the agent identifying itself as AI. That is platform
behaviour, not a setting, and compliance.ai_disclosure on the result is your
per-call record of it.
https://api.pacepayments.aihttps://sandbox.api.pacepayments.ai| Authentication | OAuth2 client credentials. The tenant comes from the token; there is no tenant header, ever. |
| Errors | RFC 9457 application/problem+json on every path, including 404s. Branch on code. |
| Idempotency | Idempotency-Key on writes, replayed for 48 hours. |
| Pagination | One envelope - data, has_more, next_cursor - on every list. |
| Rate limits | RateLimit-* headers on every response, including successful ones. |
| Timestamps | RFC 3339 with an explicit UTC offset, in both directions. |