Suppressions

A suppression stops Pace calling someone. It is checked twice, it takes precedence over everything else in the API, and one kind of entry cannot be removed over the API at all.

Creating one

curl -sS -X POST https://api.pacepayments.ai/v1/suppressions \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "phone": "+493514713160",
    "subject_reference": "CUST-88213",
    "reason": "subject_request",
    "note": "Objected by email, 2026-08-28"
  }'

You must supply phone and/or subject_reference. An entry with neither would be a block that blocks nobody: it would sit in the list looking like protection while the next call went out anyway.

Send both where you can. They do different jobs:

• phone blocks that number. If the person changes number, it stops protecting.
• subject_reference blocks the person. It keeps working when the number changes - which is exactly the case where a phone-only entry fails quietly.

This is the same person key you put in subject.reference on an order, which is why that field has to denote the same person across every order you ever submit.

Two checks, not one

The suppression list is consulted at acceptance and again immediately before dialling.

The second check is not redundancy. It is there for the objection that arrives between the two - the person who calls your office on Tuesday afternoon about an order accepted on Tuesday morning and scheduled for Wednesday. One check at acceptance would miss them entirely.

If a suppression lands while an order is in flight, the order is cancelled with cancel_reason: "suppressed".

Note

The planner deliberately leaves one tick between “dial instant computed” and “the telephone rings”, so a suppression arriving in that window still takes effect.

Scope

scope accepts only voice today.

The registry is open, so a client reading a suppression must tolerate other values appearing later. But the server rejects anything else on write, and the reason is worth understanding: v1 only makes calls. Accepting an sms entry would mean either blocking voice calls it was never meant to block, or blocking nothing at all - and Pace will not claim to block a channel it does not run.

The open registry describes what a reader must cope with, not what the server accepts.

In-call objections

When someone tells the agent not to call again, the platform creates the suppression itself. Two properties matter:

The entry exists before you hear about it. It is written before call_order.completed goes out. Otherwise there would be a window in which the result reports the objection and the list is still empty - and something reading that result could legitimately schedule another call.

You cannot delete it over the API. DELETE on an entry with source: "in_call_request" returns 409 suppression_not_deletable.

Caution

Removing an in-call objection requires a documented override reason and runs through Pace support, not through this API. Deleting a record of someone objecting is not something an API key should be able to do quietly.

A second call with the same outcome does not create a second entry or a second event.

What the objection covers

outcomes[].data.scope on do_not_call_requested is left empty. Whether the person meant “this number” or “me” is not something the runtime records.

Rather than guess, the entry blocks both, and it reports what it blocks. Guessing narrow would mean continuing to call someone who objected - a legal violation. Guessing wide is an inconvenience. The asymmetry decides it.

Sources

source tells you where an entry came from:

Value
api	Created through this API.
in_call_request	The person objected during a call. Not deletable over the API.
dashboard	Created by an operator in a Pace console.

Removing an entry

curl -sS -X DELETE "https://api.pacepayments.ai/v1/suppressions/$ID" \
  -H "Authorization: Bearer $TOKEN"

This requires suppressions:write, which is deliberately not part of config:write. Deleting a do-not-call entry is the highest-liability write in this API, and it must not ride along with permission to rename an order type. Reading the list only needs config:read - looking is not an action.

Note

A suppression created by a simulated call in the sandbox is marked internally and is deletable, so that your first test run against number +4989000000008 does not permanently block your own test record. That marking is a sandbox convenience, not part of the contract - do not rely on it in production logic.

Scope of the list

Suppressions created through this API apply to orders from this API. If you also work with Pace through other channels, contact suppression there runs through its own mechanism - ask Pace how the two relate for your setup rather than assuming one covers the other.