Call connections.request_ad_account_access
Ask the ad platform for access to the operator's own ad account — 'request access to our ad account', 'ask for access to this ad account id'. Ask the platform for permission to work on the operator's OWN ad account, naming the account id they gave you. This sends a real request that lands in their own business settings for approval, so pass the account id the operator gave you, never one you guessed. It requires a signed authorization to act on their behalf; calling it raises the approval card naming the account and the platform, which is the operator's confirmation, and only their approve sends it. It never moves money and never touches their card. Not for checking access we already asked for — that is connections.check_ad_account_access. Over the API it answers in two calls: without confirmation_id it proposes — says what would happen, returns a confirmation_id and changes, spends and sends nothing; the same arguments again with that confirmation_id, on a member's own API key, do it.
Every result names the workspace it ran in. Say which workspace the answer is about. When the account has more than one workspace and none is selected, this tool refuses with workspace_ambiguous and lists the choices — offer them, never pick one.
Request
- Base URL: https://app.goosybear.ai
- URL: https://app.goosybear.ai/api/v1/tools/connections.request_ad_account_access
- Auth: HTTP bearer
Headers
Your own id for this request, echoed back and recorded on the audit trail. 1–128 characters from A–Z a–z 0–9 . _ : -, starting with a letter or digit; anything else is replaced by a generated id.
Request body
Response
The call was admitted and dispatched. ok says whether the tool succeeded — a refusal the tool itself produced is still a 200, exactly as it is a successful JSON-RPC result over MCP.
Changes
No recorded changes to this operation across all 6 revisions of this API.