Approvals

Each workspace API key has two settings in Settings → API Keys: Deletes wait for approval and Changes wait for approval. Both are on for a new key. While one is on, a call of that kind does not run when the key makes it: it becomes a change request, and an owner or admin of the workspace approves or rejects it under Approvals in the same tab. Each request shows where the change lands (the agent, the channel, or both), what changes there (an agent's instructions section by section, the live version, who answers a channel, or each field next to how the item looks now), what approving does next, and the exact call it runs. Approving runs the call once; rejecting it, or nobody deciding within 24 hours, runs nothing.

Anyone who may edit a key can turn its approvals on; only owners and admins can turn them off. They apply to the REST API and to the MCP server alike: every MCP tool runs its REST endpoint, so a held call is held whichever way it came. Following a request needs no scope: a key reads only the requests it made.

Which calls wait

Each reference page marks these calls with Can wait for approval. A key without the scope a call needs gets the endpoint's own 403, held or not.

The answer to a held call

A held call answers 202 Accepted with the change request in data.change_request, status pending, and its URL in the Location header. Nothing has changed yet: tell your user the change waits for approval, never that it is done. Making the same call again while it waits (same method, path, query and body) answers the same request, so a retry never asks twice.

curl -X DELETE "https://www.nutalk.ai/v1/goals/7b7b8def-a340-4bfd-b164-779fa5843735" \
  -H "Authorization: Bearer $NUTALK_API_KEY"

{
  "success": true,
  "data": {
    "change_request": {
      "id": "c4a7e2d1-5b3f-4e8a-9c6d-2f1b0a9e8d7c",
      "status": "pending",
      "approval": "delete",
      "operation": "deleteGoal",
      "method": "DELETE",
      "path": "/v1/goals/7b7b8def-a340-4bfd-b164-779fa5843735",
      "summary": "Delete a goal: “Book qualified meeting” (DELETE /v1/goals/7b7b8def-a340-4bfd-b164-779fa5843735)",
      "created_at": "2026-10-13T01:30:00.000Z",
      "expires_at": "2026-10-14T01:30:00.000Z",
      "decided_at": null,
      "finished_at": null,
      "result": null
    }
  },
  "message": "This change waits for an owner's or admin's approval in NuTalk. It runs once approved; check it with GET /v1/change-requests/{id}."
}

Statuses

A request waits up to 24 hours (expires_at). Follow it with GET /v1/change-requests/:id, or list the key's requests with GET /v1/change-requests?status=pending.

What approving does

• It runs the call once, exactly as the key made it (the same endpoint, query, body and Idempotency-Key), as the key. Every check the endpoint makes runs again then, with the key's scopes as they are at that moment.
• A key revoked or expired since it asked runs nothing: the request ends failed.
• Only one decision ever lands, and a request is never run twice: one interrupted while it ran reads as failed, because the change may have been made. Check the item before asking again.

Through MCP

MCP tools return the pending request too: a tool whose call is held returns data.change_request with status pending, and the server tells the assistant to say it waits for approval, never that it is done. A key that can delete or change something and has either approval on also gets two tools to follow its requests: list_change_requests and get_change_request.

Limits