Skip to main content
POST
ProvisionManagedOrganizationAdsContainerAPI gives a managed org its own Google Ads container in

Authorizations

Authorization
string
header
required

An Erdo API key (erdo_api_...) or scoped token (erdo_token_...).

Path Parameters

orgSlug
string
required

Body

application/json
currency_code
string
customer_id
string

the org's container instead of creating a new sub-account — for an account somebody already created by hand in the Google Ads UI. Google cannot delete an account, so adopting is the only way to avoid leaving a duplicate behind. The account must be an enabled, non-manager, direct client of the MCC that no other org you manage already holds.

descriptive_name
string
replace_current_account
boolean

account being left behind. An org already running campaigns somewhere else cannot be moved into a fresh container — Google Ads has no way to move a campaign between accounts — so provisioning refuses by default rather than repointing the org at an empty account while the spend carries on where the org can no longer see it. Passing this says those campaigns will be rebuilt, and the response then names the account and the campaign count that were left behind.

time_zone
string

Response

Success response

adopted
boolean

existed under the manager's MCC (named by the request's customer_id) and was connected rather than created.

already_provisioned
boolean

delegated connection under this manager's MCC, which was returned instead of creating a second sub-account.

billing_configured
boolean

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.

billing_status
string

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.

customer_id
string

under the manager's MCC).

descriptive_name
string

Empty when AlreadyProvisioned: Erdo does not store Google's display name, and re-reading it would put a Google call on the idempotent path.

integration_id
string<uuid>
login_customer_id
string

It is the id every request against CustomerID is sent in the context of, and it names the manager DIRECTLY above the sub-account, which is not always the account the manager organization's own connection logs in as: a manager reached through a parent MCC holds its clients itself, and a container under it is addressed through it rather than through the parent.

org_slug
string
previous_campaign_count
integer<int64>

carrying — the size of the rebuild. Zero means the account it superseded had nothing in it, which is why no consent was needed to supersede it.

previous_customer_id
string

already operating when this container was provisioned, if it was operating one. That account is where its campaigns still are — nothing moved them, and no connection in the org resolves it any more.