Compliance

Some rules in this API are not parameters. They are enforced by the platform, they apply to every tenant, and no configuration value relaxes them. Your settings can narrow them; nothing widens them.

This page states what those rules are, so that you can design around them rather than discover them at a 422.

Calling hours

Calls are placed Monday to Saturday, 08:00 to 21:00, in the timezone of the person being called - not yours, and not Pace’s. Sundays and public holidays are excluded.

Holiday tables are applied per resolved timezone: German holidays for Europe/Berlin, Czech holidays for Europe/Prague. A timezone with no table runs without holiday exclusion rather than failing shut, on the grounds that a call on a holiday is a smaller problem than a silent total outage.

Set subject.timezone to an IANA zone. If you omit it, it is derived from country or from your tenant configuration - but deriving it is a guess, and a debtor who has moved is the case where the guess is wrong.

How your window is combined

actual = your window
       ∩ statutory calling hours
       ∩ your tenant's configured hours
       ∩ the per-subject daily cap
       ∩ available capacity

Intersection, always. scheduling.local_call_times is a narrowing within the statutory window - sending 08:00–22:00 does not buy you an extra hour; it buys you 08:00–21:00.

When the intersection is empty, on_window_violation decides:

Value	Behaviour
defer (default)	Move into the permitted window. The order may eventually expire.
reject	Refuse acceptance with 422 on_window_violation.

Choose reject when a call outside your intended window is worse to you than no call at all - for a time-sensitive campaign, a call that arrives three days late may be worse than none.

Note

Dial instants sit on a fifteen-minute grid, and the search looks 30 days ahead. A window with no permissible instant in that horizon is rejected at acceptance with window_unsatisfiable rather than accepted and quietly expired a month later.

AI disclosure

The agent identifies itself as AI in the opening of every call. This is platform behaviour built into every conversation profile. It cannot be switched off, and there is no field that requests it or suppresses it.

compliance.ai_disclosure on the result is your per-call record:

{
  "ai_disclosure": { "disclosed": true, "at": "2026-08-30T09:14:22+02:00" }
}

It hangs off the answered call rather than standing at a blanket true, so it records what happened on this call instead of asserting what the configuration says.

What the agent will not do

It does not conclude agreements. An instalment plan discussed on the phone comes back as a recorded wish - installment_plan_requested in outcomes[]. The binding arrangement is one you make afterwards, in writing.

This is not a default you can change. conclusion_mode is a single-value literal in the schema precisely so that no configuration edit can turn it into something else. The same holds for settlements: negotiation.settlement.min_ratio: 0.6 means the agent may note a 60 per cent offer, not accept one.

It does not exceed the negotiation corridor. Whatever the order type permits is a ceiling. An order may narrow it; an order that tries to widen it is rejected with 422 negotiation_exceeds_policy.

It does not improvise legal consequences. claim.titled tells the agent whether an enforcement title exists. It changes what may be said about consequences and it extends the limitation period, which is why it is never inferred - you set it explicitly or it is false.

It does not make marketing calls. Order types bind to conversation profiles vetted by Pace, and you cannot reference a profile Pace has not created. That binding is what makes the restriction enforceable rather than contractual.

Contact frequency

A per-subject daily cap limits how often the same person can be contacted, and it is applied as part of the window intersection. Your max_attempts operates inside it, not around it.

randomize_within_window scatters redial instants so the same person is not called at the same minute every day. Leave it on: a predictable daily call at 09:03 reads as harassment even when the count is lawful.

And a rule from the retry policy that belongs here too: a conversation is never retried. Not when the outcome disappointed you, not when the debtor was non-committal. Only attempts that failed to reach a live counterpart can trigger another.

Identity verification

Before discussing a claim, the agent confirms it is speaking to the right person. The mode is configured for your tenant and determines which subject fields an order must carry:

Mode	Requires
birthday	Date of birth.
name_address	Name and address - including postcode and house number.
address_birthday	Address and date of birth.
plz	Postcode only.

Caution

name_address needs the postcode as well as the street. The platform matches name against postcode and house number in this mode, and an address without a postcode cannot pass. The API enforces this at acceptance so the failure surfaces in your integration rather than mid-call, in front of a real person.

Read your mode from GET /v1/tenant rather than hard-coding it.

result.identity reports what happened: verified, the method used, and attempts where a real counter exists. attempts is not the dial count - those are two different things.

Recording

Recording is switched off platform-wide. GET /v1/calls/{call_id}/recording answers 404, and the recordings:read scope grants nothing today. This is current behaviour, not a feature awaiting release.

Transcript retention

Transcripts are deleted after the result is delivered - seven days later by default. calls[].transcript.expires_at is the deadline, and from that instant the endpoint answers 404.

Caution

If you may need a transcript for a dispute or an audit, copy it into your own case file when the result arrives. There is no recovery afterwards, and no endpoint that restores one.

delivery.transcript controls how much you get (none, summary_only, structured), capped by your tenant’s retention rule.

What the compliance block does not tell you

compliance.statutory_disclosure is currently always empty. Whether the creditor was named and the cost basis explained lives only in the wording of the conversation. Filling these fields without analysing the transcript would make every one of them an assertion rather than a record.

Do not build a compliance report on this block. An honestly empty field is better than a full one nobody checked.

Transcript.redactions is likewise always empty: the platform does not redact transcript content today.

Data you send

metadata is opaque key-value data, mirrored onto resources and into every event.

Caution

It is contractually free of personal data. Pace does not inspect the values, and what you put there falls outside the deletion and retention machinery that protects the rest of the order. Put your campaign identifier there; do not put a name.

There is no access or erasure endpoint in v1. Those requests run through Pace support, and subject.reference is what makes them answerable - which is why it must denote the same person across every order you submit.