For developers
Confirmed actions
A fail-closed contract for changing external-product data without giving the model direct write access.
Updated: August 10, 2026
01
Draft capability
jsonKanyman docs
{
"name": "prepare_delivery_retry",
"capability_version": "1.0.0",
"side_effect": "draft",
"confirmation_policy": "required",
"idempotency_policy": "required",
"method": "POST",
"url": "https://api.example.com/kenyman/actions/delivery-retry"
}02
Lifecycle
textKanyman docs
awaiting_confirmation
→ confirmed
→ executing
→ succeeded | failed | unknown_result
awaiting_confirmation | confirmed
→ cancelled
awaiting_confirmation
→ expiredThe product endpoint is not called before server-side confirmation. The action may be confirmed by a project owner/admin in the account or by an end user in their authenticated Web Chat session. After confirmation, the action enters a durable queue and is handled by a separate worker.
03
Request to your endpoint
httpKanyman docs
POST /kanyman/actions/delivery-retry
Idempotency-Key: action_...
Authorization: Bearer ...
X-Kanyman-Key-Id: connector-current
X-Kanyman-Timestamp: ...
X-Kanyman-Nonce: ...
X-Kanyman-Body-SHA256: ...
X-Kanyman-Signature: ...
{
"request_id": "ktc_action_...",
"integration_id": "ext_...",
"action_id": "action_...",
"capability_version": "1.0.0",
"subject": "opaque-user-reference",
"entities": [{ "type": "project", "ref": "prj_..." }],
"input": { "request_id": "req_..." }
}- Treat Idempotency-Key as the operation’s unique key and return the same result for retries.
- Do not trust browser-provided subject, integration_id, action_id, or capability_version values.
- Keep the link between action_id and the internal operation for manual reconciliation.
04