Push-only. You call Regent on your own trigger cadence; Regent does not connect to your EMR, CRM or any other system, and you do not maintain a webhook to receive decisions. You call Regent when your own scheduler decides it is time; Regent decides whether the outreach is allowed, dispatches it if so, and records why either way.
Three steps, and none of them is a webhook you have to build.
A DecisionRequest carries your snapshot of the subject — timezone, signals, consent evidence, outreach history, a conversation summary. You assemble it; Regent does not reach into your systems to get it.
Hard stops run before the judgment engine. Your governance rules run after the proposal. If the outcome is a send, governed dispatch from your own meta business identity.
The operation resource carries the terminal state, the full gate chain, dispatch and provider state, escalation state, and the audit trace id. tamper-evident with governed redaction.
Land-in-days integration is the design target — one push endpoint, no agents to configure, no inbound access. No integration-time guarantee is published. The number will be stated when it has been measured against real tenants.
There is no tenant_id field to spoof. Regent derives tenancy from the credential that authenticated the call, and the credential is a server-side secret.
Every sample on this page uses the placeholder <tenant-token>. A real tenant console will hold its credential behind a server-side session boundary before a browser ever talks to a tenant-scoped API.
One to check your payload shape, one to act.
Validates a snapshot against your issued schema contract. No decision is made and nothing is dispatched.
POST /v1/validate
Authorization: Bearer <tenant-token>
Content-Type: application/json
{
"schema_version": "customer-snapshot.v1",
"snapshot": { "timezone": "Africa/Cairo", "conversation_summary": "..." }
}Submits a governed request. Tenant identity comes from authentication only, never from the request body.
POST /v1/engage
Authorization: Bearer <tenant-token>
Content-Type: application/json
{
"request_id": "req_01J...",
"subject_id": "subject_441",
"schema_version": "customer-snapshot.v1",
"expected_config_version": "cfg_12",
"snapshot": {
"timezone": "Africa/Cairo",
"conversation_summary": "..."
},
"delivery": {
"recipient": "<tenant-asserted address>",
"template_ref": "followup_v2",
"language": "en"
},
"subject_sequence": 18
}| Field | Type | What it means | |
|---|---|---|---|
| request_id | string | required | Caller-stable identity. Same id + same content is a retry that returns the original operation. |
| subject_id | string | required | Your identifier for the person. Regent never resolves it to a contact record. |
| schema_version | string | required | The snapshot schema contract you were issued, e.g. customer-snapshot.v1. |
| expected_config_version | string | optional | A check, never a choice. A mismatch is reported rather than silently resolved. |
| snapshot | object | required | What you already know: timezone, signals, consent evidence, outreach history, conversation_summary. |
| delivery | object | required | Recipient assertion plus template refs and language. The recipient is yours to assert and stays outside the judgment runtime. |
| subject_sequence | integer | optional | Informational only. Echoed in the audit record, never enforced. |
202 Accepted
{
"operation_id": "op_01J...",
"request_id": "req_01J...",
"status": "accepted"
}Illustrative. Acceptance is immediate and the operation completes within the processing promise; the exact response envelope is finalised with the signed API build.
409 Conflict
{
"error": "idempotency_reuse_conflict",
"request_id": "req_01J...",
"detail": "This request_id was already accepted with different content."
}Illustrative. Same request_id with different semantic content is a conflict, not a second operation.
None of these is a preference. They are the behaviour you will observe, so they are documented as contract.
Same request_id with the same semantic content is a retry and returns the original operation. Same request_id with different content is an idempotency-reuse conflict. Idempotency records outlive every retry, webhook and dispute window.
Each accepted request is processed on its own snapshot, in arrival order per subject, to completion. Regent does not arbitrate between your own concurrent pushes — the published rate limits are the contract. Multiple accepted pushes for one subject inside a short window raise an anomaly flag that surfaces as information and never blocks.
subject_sequence is informational only — it is echoed in the audit record and never enforced.
Regent's freshness guarantee begins when Regent receives the push. The snapshot timestamp inside the request is tenant-asserted metadata and is never the basis of that guarantee; data age before the push is the tenant's pipeline responsibility.
When the provider send response is lost, no provider-backed correlation exists. Matching on recipient and timestamp is a heuristic that can support investigation, and it never establishes acceptance. The state stays unknown until a provider-supported identifier resolves it, or an operator resolves it manually.
The decision dossier the judgment engine sees and the delivery envelope that carries the recipient are different objects. Raw addresses never enter the judgment runtime; every dispatch audit row records the recipient as asserted by you, against the pushing request.
One table drives the API, the console, the audit record and the billing ledger. Handle these and you have handled Regent.
Dispatch authorized and accepted by the provider.
Terminal hold · no dispatch. Future outreach requires a new customer-triggered request.
Suppression active for this subject and intent. It ends only on a trigger-fingerprint change, an authorized clear, or TTL expiry.
Outreach blocked. The named human escalation target was alerted.
Operation ended · no queue · customer re-push required.
The provider rejected the dispatch. Retry behaviour follows the declared retry class.
Provider acceptance unresolved · no blind retry · investigation required.
A controlled failure inside the decision path. Recorded, not billed, not silently retried.
Read them rendered against real gate chains in the synthetic decision feed.
Nothing on this page is a publicly connected endpoint today. The contract is frozen and the surface renders it against synthetic fixtures; each capability connects when the sprint that owns it is integrated.
The Governance Playground puts the same gate chain in front of you with nothing connected. If the semantics fit your problem, the pilot conversation is short.
Security and data-handling posture: Trust & data handling →