ProvisionManagedOrganizationAdsContainerAPI gives a managed org its own Google Ads container in
one call: a fresh sub-account under the MANAGER org’s Google Ads manager account (MCC), plus a delegated google_ads connection in the managed org that operates it. Idempotent — an org that already has a delegated connection under this MCC gets it back (already_provisioned: true), never a second sub-account. Deliberately no MCP tool: creating a billable provider account and a durable delegated credential stays off the model-facing tool surface, like manager-key minting and member adds (see the file header).
Authorizations
An Erdo API key (erdo_api_...) or scoped token (erdo_token_...).
Path Parameters
Response
Success response
delegated connection under this manager's MCC, which was returned instead of creating a second sub-account.
setup, which is what decides whether it can serve. A container is created with none: Google's BillingSetupService can only attach one programmatically for customers on monthly invoicing, so until the MCC is approved for that, somebody has to link a payments profile in the Google Ads UI. Saying so here is the difference between a known remaining step and one discovered at go-live, when the campaigns are built and nothing serves.
APPROVED_HELD, CANCELLED. Two values are ours rather than Google's: "none" when the account has no billing setup at all, and "unknown" when the check itself could not be made. Those are different facts and a caller gating go-live must not read the second as the first — an unreadable answer is a reason to go and look, not evidence of absence.
under the manager's MCC).
Empty when AlreadyProvisioned: Erdo does not store Google's display name, and re-reading it would put a Google call on the idempotent path.
the id every request against CustomerID is sent in the context of.

