RCS for Business: Access, Roles & Permissions

RCS for Business separates three parties: the brand that owns an agent (the programmatic sender that represents the brand in Google Messages), the partner or developer — typically an RCS Solution Provider — that builds and operates the agent, and the carriers on whose networks the agent launches.

Partners register in the developer console using an individual, corporate-domain Google Account (not a consumer Gmail or a group account) (Google — Register as a partner).

Google fully transitioned to a partner/aggregator model — legacy standalone brand onboarding was deprecated and its docs removed. Brands access RCS for Business only through a certified partner or CPaaS (Twilio, Sinch, Infobip and others).

This puts RCS in the same "mandatory intermediary" category as Apple Messages for Business and KakaoTalk: there is a REST API, but a brand cannot self-onboard to it.

The documented in-console role model is minimal. There is a Partner Account Owner — who can create and manage agents and API credentials, and whose email is recorded as the agent_owner in carrier billing — and a Technical Point of Contact named to handle deployed-agent issues.

Google does not publish a fine-grained owner/admin/agent/analyst permission matrix, so beyond these named contacts the internal seat model is lightly documented (Google — Brand verification).

Because the partner operates on the brand's behalf, going live requires brand verification: an authorized brand representative confirms the agent's details and the partner's right to manage it. The agent then seeks launch approval, which is either Google-managed or carrier-managed, and moves from Pending to Launched per carrier. Once approved, a verified checkmark appears beside the agent in Google Messages.

In practice the operating partner holds the technical/API credentials to send through the agent, while the brand authorizes that relationship and can revoke it by withdrawing its verification.