> ## Documentation Index > Fetch the complete documentation index at: https://docs.apostra.com/llms.txt > Use this file to discover all available pages before exploring further. # Approving agent requests > Why some agent actions wait for a person to approve them on the Apostra site, and how approval works Some actions are too consequential to run just because an agent asked. For those, Apostra records the agent's request and waits until a person approves it on the Apostra site. The agent gets a link to share with that person; nothing happens until they approve. ## Which actions need approval An action needs approval when it grants or removes access to an account, creates an account or another commercial commitment, or cannot be undone. Routine and reversible work, such as reading, drafting and edits you can undo, runs straight away on the authority you gave the agent. The page for each action says whether it needs approval. These actions need it today: * [Creating a Buyer child account through MCP](/v2/buyer/account/overview#create-a-buyer-child-through-mcp) ## Why the approval happens on our site When an agent calls Apostra through MCP or the API, Apostra cannot tell whether a person is behind that particular call or the agent chose to make it. An agent's client could also show a convincing "Approve?" button that the agent controls. So for these actions the approval happens somewhere the agent and its client are not involved: a page on the Apostra site, opened in your own browser and signed in with your own login. This follows the approach the MCP specification recommends for interactions that must not pass through the model or the client. ## What the agent receives The action does not fail. The agent receives an `approval_required` result with: * a link to the approval page, `https:///approve/` * the approval's state * when it expires If the agent's client supports MCP URL-mode elicitation and keeps a streaming connection, it also receives the link once as a prompt it can show you directly ("open to approve"). Apostra does not push a notice at the moment you decide. When the agent next repeats the request and the approval is final, the client also receives the elicitation completion notice on that same connection. Clients without that support get only the result above, which already includes the link. The link carries only an unguessable id: no account name, no operation details and no token. The agent shows you the link and checks the outcome later by repeating the same request with the same idempotency key. Repeating the request never creates a second approval, and reusing the key for a different request is refused. ## Who can approve Only a person who: * is signed in to the Apostra site in their own browser, and * holds the role the action requires on the account, usually administrator. API keys, service tokens, MCP access tokens, impersonated sessions and support sessions cannot approve, even for a user who holds the role. Apostra checks the role when the page opens and again at the moment the person approves, so removing someone's role stops them approving from then on. The person who approves does not have to be the person whose agent asked. Any administrator of the account can approve or reject. ## What the page shows The approval page shows what will happen, which account it applies to, who asked for it and how they authenticated (for example, "a personal API key"), which client the request came through, and the deadline for deciding. The client is recorded from the requester's own connection, never from what the request says about itself: an MCP client the connection identified (for example "Claude over MCP"), "An MCP client" when it did not identify itself, or "The REST API". If you do not recognise the client, reject the request. ## What happens next | Outcome | What it means | | - | - | | Approved | The recorded request runs once, as the person who approved it, with the same checks as the direct request. If it cannot finish straight away, it keeps trying and still runs only once. | | Completed | The action happened. The agent sees the result when it checks. | | Could not be completed | The action refused after approval, for example because an account limit was reached. Nothing took effect, and the agent must make a new request. | | Rejected | Nothing happens. The agent must make a new request if it is still needed. | | Expired | Nobody decided in time. Requests expire after 24 hours unless the action sets its own window, which is never longer than 7 days. Nothing happens. | Once a request is final, Apostra deletes the detailed request data it kept for running the action, and keeps only the outcome and an audit record of the decision. ## Limits An account can have at most 50 requests waiting for approval, and one user can make at most 100 approval requests an hour. Beyond that, new requests are refused until some are approved, rejected or expire. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.