Idempotency keys
Every mutating call carries an Idempotency-Key. Retrying a request never creates the same visit twice.
Developers
A REST API we use ourselves.
Aldor is steered through exactly the API you see here. Tax advisors plug in payroll, payroll bureaus pull visits, your own analytics tooling fetches client and tour data — with OAuth tokens, idempotency keys, and an honest RFC-9457 error convention.
Example
One visit, created.
REST over JSON, OAuth bearer tokens, every mutating endpoint takes an idempotency key. No bespoke SDK language, no required toolchain — curl is enough for an integration.
Cursor pagination
List endpoints paginate by cursor, not offset/limit. Stable ordering even under concurrent writes.
RFC 9457 problems
Errors come as application/problem+json with type, title, detail, errors. No creative HTML response page with a 200 status.
Request
POST /api/v1/visitscurl https://aldor.ai/api/v1/visits \
-H "Authorization: Bearer alkr_live_…" \
-H "Idempotency-Key: 3f1d-…" \
-H "Content-Type: application/json" \
-d '{
"client_id": "01HSV…",
"helper_id": "01HSW…",
"starts_at": "2026-04-30T10:00:00Z",
"services": ["betreuung"]
}'
Response
201 CreatedHTTP/2 201 · 84 ms
{
"id": "01HSXYZ…",
"status": "scheduled",
"x-agent-allowed": "propose",
"next_actions": [
"sign", "reschedule"
]
}
AI tokens
Affordances for AI agents — built in, documented, bounded.
Aldor is built so AI agents can read and propose without doing damage. The API gives tokens three affordances — read, propose, forbidden — and marks per endpoint what's allowed.
x-agent-allowed
What can this token do?
Every response carries an x-agent-allowed field — read, propose or forbidden. The header tells the agent which follow-ups are permitted.
"x-agent-allowed": "propose"dry_run
Dry runs without writes
Mutating calls accept ?dry_run=true. You get the validation and the computed result — but nothing is persisted. The agent can show "the tour would look like this" before anyone clicks.
POST /api/v1/visits?dry_run=trueconfirmation_token
Two-step confirmation
Risky actions (Abtretung, Pflegegrad change) return a confirmation_token in a 202. The token is redeemed in a second call — after a human clicks.
"confirmation_token": "ctok_…"clinical_guardrail
Clinical guardrails
Certain endpoints are marked token-affordance forbidden — no token, even a human-controlled propose token, can fire them without extra confirmation. List below.
x-clinical-guardrail: hardWhat no token can do
Five actions only a human triggers.
The following actions are hard-guarded in the API. Even a read+propose token can't fire them — two-step confirmation with human interaction is mandatory.
-
Sign an Abtretungserklärung
Sign a § 45b assignment to a provider — only by human click in the Aldor frontend.
-
Change a Pflegegrad
Modify a client's care level — even an ops token needs a second confirmation.
-
Submit Pflegekassen billing
Send the aggregate invoice to the Pflegekasse — owner account with MFA confirmation only.
-
Release a payroll run
Release a payroll run to the tax advisor — owner account with MFA confirmation only.
-
Bulk-export client data
Bulk exports above 100 clients — owner account with MFA confirmation and audit log.
Get started
Let's talk briefly.
A demo takes thirty minutes. You show us your day. We show you Aldor with your data. If it doesn't fit, we'll say so.