Apply a configuration document in the sandbox
Creates or updates every object in the document in one atomic step, or none of them. Objects with a key are matched by key, webhook endpoints by url, and the routing rules and notification rules in the document replace the current lists. Nothing in the account is deleted because it is missing from the document: it merges, and only PUT /v1/config removes. Sandbox keys only: a live key gets 403 with proposal_required, and live changes go through POST /v1/config_proposals. Each created or changed object records the actor that made the change. Needs config:write.
Authentication
A secret key (rl_sk_test_..., rl_sk_live_...) or a restricted key with limited scopes (rl_rk_test_..., rl_rk_live_...). A restricted key can carry agent: true and an expires_at, and is what a coding agent should hold. Keys end in a checksum so secret scanners can recognize them. People create, roll and revoke keys in the dashboard; GET /v1/api_keys lists them, masked.
Headers
Send true to see what the write would do without doing it. The response is the normal body with dry_run: true, changes (path, before, after), warnings and errors added, and nothing is stored. Validation runs as it would for a real write. The request is kept in request logs, tagged Dry run. When the same change is then made for real, its audit event has dry_run_preceded: true.
Request
Everything an agent or person configures, in the shape the create requests take. Leave a section out to leave it alone. Objects with a key are matched by key, webhook endpoints by url. Routing rules and notification rules are ordered lists that replace the current ones. Payment providers are connected with POST /v1/payment_providers, because a person completes that step.
Response
What was created or changed. Only when applied.
The configuration’s hash after the change. Only when applied.
The config proposal ID. Only when proposed.