post_approvals_signups_by_id_approve
Calls POST /api/approvals/signups/{id}/approve as the signed-in person · REST reference
Approve a pending organization signup
Approves the signup in the graph and emails the contact a welcome message. The email is BEST EFFORT — a mail failure is logged and the approval still answers 200, so a 200 does not mean the applicant was told. The path id is the CONTACT USER id, exactly as GET /api/approvals/signups returns it in each row's id, not the org id. Answers the { success, data } envelope, unlike its sibling reject route which answers { success } alone. An id with no pending signup is 404 (the DAL's sentence), an id that is not a UUID 400, an unreachable DAL 503, any other failure 500 — never upstream text.
Arguments
| Argument | Type | Description | |
|---|---|---|---|
idpath | string (uuid) | required | Contact user id of the signup, from the queue row's id. |
Example call
A client sends this over the MCP session; Claude and other agents build it for you. The values are placeholders — the shape is real.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "post_approvals_signups_by_id_approve",
"arguments": {
"id": "11111111-1111-4111-8111-111111111111"
}
}
}Result
On success (HTTP 200) the tool returns one text item holding the API's JSON, pretty-printed.
The signup was approved. The row is the post-approval state.
{
"data": {
"address": "string",
"businessTypes": [
"string"
],
"contactName": "string",
"createdAt": 1,
"email": "name@example.org",
"id": "11111111-1111-4111-8111-111111111111",
"orgId": "11111111-1111-4111-8111-111111111111",
"organizationName": "string",
"organizationType": "string",
"phone": "string",
"status": "string",
"taxId": "string"
},
"success": true
}Fields
| Field | Type | Description |
|---|---|---|
data | object | The same row shape GET /api/approvals/signups returns, with status now reflecting the approval. |
data.address | string | null | |
data.businessTypes | array of string | |
data.contactName | string | |
data.createdAt | integer | Epoch MILLISECONDS. |
data.email | string (email) | |
data.id | string (uuid) | The contact user id. |
data.orgId | string (uuid) | |
data.organizationName | string | |
data.organizationType | string | |
data.phone | string | null | |
data.status | string | |
data.taxId | string | null | |
success | true |
When it fails
A failed call returns isError: true with the API's message as text. A change the person declines, or lets time out, also comes back this way and nothing changes.
400The request was malformed or failed a guard.
403Authenticated, but the caller holds none of the required permissions.
404No such resource — or none this caller may see.
What the model is shown
This is the tool exactly as the server lists it in tools/list. The description starts with the REST call it makes.
{
"name": "post_approvals_signups_by_id_approve",
"description": "POST /api/approvals/signups/{id}/approve — Approves the signup in the graph and emails the contact a welcome message. The email is BEST EFFORT — a mail failure is logged and the approval still answers 200, so a 200 does not mean the applicant was told. The path id is the CONTACT USER id, exactly as `GET /api/approvals/signups` returns it in each row's `id`, not the org id. Answers the `{ success, data }` envelope, unlike its sibling reject route which answers `{ success }` alone. An id with no pending signup is 404 (the DAL's sentence), an id that is not a UUID 400, an unreachable DAL 503, any other failure 500 — never upstream text.\n\nThis changes data. The person is asked to confirm it before it runs, and nothing happens if they decline.",
"inputSchema": {
"type": "object",
"properties": {
"id": {
"type": "string",
"description": "Contact user id of the signup, from the queue row's `id`."
}
},
"required": [
"id"
]
},
"annotations": {
"readOnlyHint": false,
"destructiveHint": true,
"idempotentHint": false,
"openWorldHint": false
}
}