Create a real Google account with a browser agent and an OP Number
For many agent workflows, the account is not created through a Google API. A browser agent opens the same consumer signup flow a person would use, enters a delegated OP Number, receives the SMS challenge, and keeps that number available for later 2FA and recovery.
Start with a real delegated browser flow
A browser agent is useful because it can operate the web as it exists. It can visit Google's consumer account flow, fill ordinary fields, wait for a phone challenge, read the SMS code, and continue in the browser.
The important part is that the flow is delegated. A human or organization authorizes the account, decides what information the agent may enter, and remains accountable for the identity. The agent should stop for CAPTCHA, Terms, unusual security prompts, or anything it is not explicitly allowed to decide.
OP gives that browser flow a durable carrier number. The number is not a one-time signup trick; it becomes the phone identity the account can use again when Google asks for a code later. For more on why that distinction matters, read VoIP numbers vs carrier numbers for agents.
goal: Create one user-authorized Google consumer account
actor: browser agent
phone: OP_NUMBER
rules:
- do not bulk-create accounts
- do not bypass CAPTCHAs, anti-abuse checks, or account review prompts
- pause for the human on Terms, CAPTCHA, recovery choices, or uncertainty
- use the OP Number only for this delegated account identity
- save the account, OP number ID, and owning human in your audit log
flow:
- open the normal Google account creation page
- fill fields the human has authorized the agent to fill
- enter OP_NUMBER when Google asks for a phone number
- read the inbound SMS code from OP
- submit the code in the browser
- keep the OP Number attached for future 2FA and recoveryConsumer accounts need continuity
A consumer Google account becomes useful to an agent only after it survives the normal lifecycle of an account: first verification, later sign-ins, suspicious-login checks, password resets, device changes, and recovery prompts.
That is where the phone number matters. If the agent used a one-off inbox or VoIP-style number during signup, the account can get stranded the next time Google asks for a text code. If the account uses an OP Number, the same phone identity remains available through the API whenever an authorized 2FA or recovery flow needs it.
Get the OP Number for the agent
Before the browser agent starts the Google flow, give it the OP Number it is allowed to use. The agent can fetch the number from OP, then enter that number when Google asks for a phone number in the browser.
const OP_API_KEY = process.env.OP_API_KEY;
async function getOpNumber() {
const response = await fetch("https://api.op.inc/v1/number", {
headers: {
Authorization: `Bearer ${OP_API_KEY}`,
},
});
if (!response.ok) {
throw new Error(`OP number lookup failed: ${response.status}`);
}
const payload = await response.json();
return payload.number.e164;
}
const opNumber = await getOpNumber();
console.log(opNumber); // +16176088932Let the browser agent use the number
The agent does not need a Google provisioning API for a consumer account. It needs browser access, the delegated account details, and the OP Number. When the signup flow asks for phone verification, the agent enters the OP Number exactly as it would enter a human-owned number.
If Google shows a CAPTCHA, abuse review, or a prompt that requires human judgment, the agent should pause. The goal is not to hide that software is involved. The goal is to let delegated software use a durable phone identity in a real account flow.
Read authorized SMS challenges
When Google sends a code to the OP Number, the browser agent can read inbound messages from OP and type the code into the active browser step. Keep the workflow scoped to the account the user delegated to the agent.
async function latestInboundCode() {
const response = await fetch(
"https://api.op.inc/v1/messages?direction=inbound&limit=20",
{
headers: {
Authorization: `Bearer ${process.env.OP_API_KEY}`,
},
},
);
if (!response.ok) {
throw new Error(`OP messages lookup failed: ${response.status}`);
}
const payload = await response.json();
const messages = payload.data ?? payload.messages ?? [];
for (const message of messages) {
const code = message.body.match(/\b\d{6}\b/)?.[0];
if (code) return code;
}
return null;
}Use the number for 2FA and recovery
Two-factor authentication is not just a signup hurdle. For agents, it is part of the operating model. The agent needs a way to receive a code when a session expires, when Google asks for a fresh challenge, or when a human operator is recovering the account.
Keep this flow explicit. A human or authorized system should initiate the sign-in or recovery step, and the agent should read only the messages for its assigned OP Number. The code becomes an auditable event tied to the same account identity.
async function waitForGoogleCode(timeoutMs = 60_000) {
const startedAt = Date.now();
while (Date.now() - startedAt < timeoutMs) {
const code = await latestInboundCode();
if (code) return code;
await new Promise((resolve) => setTimeout(resolve, 3_000));
}
throw new Error("No Google verification code received in time");
}
const code = await waitForGoogleCode();
console.log(`Use this code in the authorized 2FA step: ${code}`);Keep the account accountable
Use one dedicated OP Number per durable agent identity when continuity matters. Store the Google account handle, the OP number ID, the owning human or system, and the account recovery policy in your database so you can audit who delegated the account.
Rotate API keys, avoid shared inboxes for production agents, and keep a human review step around unusual security prompts. The point is not to look more human; it is to make delegated software easier to identify and recover.
This is part of a broader identity pattern. Read Agent identity for the web for the larger model behind delegated account workflows.