Approves an access request and materializes the proposed addition to the participant graph.
Body's `mode` picks the commit shape: <list type="bullet"><item><b>createNew</b> — create a new Person participant from the observed sender, with one channel `{integrationConfigId, address}` from the request, and bind it to the request's agent.</item><item><b>addToExisting</b> — append the channel to an operator-chosen existing participant (`participantId` required) and ensure the binding to the request's agent.</item><item><b>bindOnly</b> — write just the agent binding; the channel already exists on the matched participant.</item></list> Returns 400 if the request is not in Pending, or if the requested mode is missing the field it requires (e.g. `bindOnly` on a request without a matched participant). Requires Editor role on the request's agent — enforced inside the service since the route doesn't carry the agent id.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The participant access request ID.
uuidThe tenant identifier
Approve payload — mode + mode-conditional fields.
How an access request commits on approve. See §11 of agent-network.md.
"UNSPECIFIED" | "CREATE_NEW" | "ADD_TO_EXISTING" | "BIND_ONLY"Operator-supplied name for the new participant. Optional in
createNew mode — falls back to the request's
DisplayName, then to the address. Ignored in the other modes.
length <= 150Existing participant to extend / bind. Required in addToExisting
mode; ignored otherwise (in bindOnly the matched participant is
read off the request row itself).
uuidOptional audit note recorded on the request row.
length <= 4000Response Body
curl -X POST "https://api.fruxon.com/v1/tenants/string/participantAccessRequests/497f6eca-6276-4993-bfeb-53cbbbba6f08:approve" \ -H "Content-Type: application/json" \ -d '{}'{
"id": "00000000-0000-0000-0000-000000000000",
"integrationConfigId": "00000000-0000-0000-0000-000000000000",
"provider": "string",
"address": "string",
"agentId": "string",
"matchedParticipantId": "00000000-0000-0000-0000-000000000000",
"displayName": "string",
"conversationName": "string",
"status": "PENDING",
"processedBy": "string",
"processedAt": 0,
"processingNote": "string",
"approvedParticipantId": "00000000-0000-0000-0000-000000000000",
"createdAt": 0,
"modifiedAt": 0
}{
"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
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}Lists access requests in the tenant, filterable by agent / status / matched-or-approved participant.
The Agent Network overview tab calls this with `agentId` set to the current agent and `status=pending` to render the pending queue. The tenant-level triage page calls it without filters. Returns every match — paging is intentionally not modelled in v1 because the pending queue is bounded by operator throughput, not message volume.
Retrieves a specific access request by ID.
Loads the full access request row for operator review, including the proposed sender channel, matched participant (when one was found), and processing metadata. Use this before approving or rejecting when the list view does not include enough context for the decision.