Removes the slot's binding
Returns 204 whether or not a binding existed. The slot declaration on the revision is untouched; only the participant wiring is removed.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The agent identifier.
The slot name.
The tenant identifier
Response Body
curl -X DELETE "https://api.fruxon.com/v1/tenants/string/agents/string/slots/string/binding"{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}Binds a participant to a declared slot
The participant shorthand for the binding endpoint above — equivalent to a body of `{ "bindingType": "PARTICIPANT", "participantId": … }`. Validates that the slot is declared on the agent's current revision and that the participant kind matches the slot's `RequiredKind`. Re-binding the same slot replaces the participant in place — the binding id is preserved across replacements so any downstream audit references stay correlatable.
Binds a declared slot to a participant, a roster role, or the operator queue
The body's `bindingType` chooses how the slot is fulfilled (HITL unification design §3.2): `PARTICIPANT` names one person, `ROLE` defers to whoever holds that roster role in this Application — the same selection `consult_for_role` uses, so notify and consult cannot name different humans — and `QUEUE` routes to the awaiting-human queue. Re-binding replaces the binding in place; the binding id is preserved so downstream audit references stay correlatable. A binding says who gets <em>delivered to</em>. It is never a grant to answer or act — that is checked separately, at answer time (design §5.4).