Read this before you pick a target
Automated signup does not work everywhere, and pretending otherwise wastes your time:- Phone-verified signups cannot complete. Sente identities are email-only. A site that demands
an SMS code at signup —
x.comis the canonical example — blocks withPHONE_REQUIREDand waits for a human to supply a number in the live view. If nobody does, the run fails after the hold. Check for a phone step before you aim at a site. - CAPTCHAs stop the run. Sente does not complete CAPTCHAs. The run blocks with
CAPTCHA_REQUIREDand a person solves it in the interactive live view, then resumes. That is the design, not a gap. - Fraud and abuse walls are real. Some apps silently reject or shadow-block signups they judge
automated — sometimes before any verification email is sent. Those runs end
failed. Sente cannot make a site accept a signup it has decided to refuse. - Payment walls stop the run.
PAYMENT_REQUIRED; Sente never enters payment details.
A failed run does not consume your run quota — only non-failed runs count against the daily and
monthly caps. It does consume time and browser minutes, which is reason enough to check the target
first.
Register an account
POST /v1/registrations with the signup URL. identityId is optional — omit it and the account’s
email address is provisioned from the app’s hostname (https://example.com/signup →
example@sente.run). Credentials are optional too: supply a username and password, or let Sente
derive a username and generate a strong password.
0/O, 1/l/I)
excluded so it survives copy-paste into a signup form. Either way it is vaulted AES-256-GCM and
readable back through getCredentials — created accounts only, and every read is written to the
audit trail.
Don’t call
waitForOtp around a registration. Verification is completed inside the run: the
inbound email is classified on arrival, the code or link is extracted, and the run controller applies
it. Those helpers are for signups your own code drives — see
Verification codes.Confirm-before-submit
PassconfirmBeforeSubmit: true and the agent fills every field and ticks the terms checkboxes, then
deliberately stops without pressing the final button. The run blocks with
SUBMIT_CONFIRMATION_REQUIRED and a liveViewUrl. A person opens it, reviews the filled form,
clicks submit themselves — so a human, not an agent, forms the agreement with the site — and resumes
the run. Sente then finishes email verification as usual.
Calling register twice
Registration is idempotent per (identity, app origin), so a retry is safe:Failure paths
Call-time errors:
Run outcomes. Everything in the first group blocks and waits for a person; nothing is
circumvented:
After the run completes
sente credentials <registrationId>/getCredentials(id)— the vaulted{ username, password, origin }.sente relogin <registrationId>/registrations.login(id)— re-authenticate later; returns a fresh{ registration, run }.sente session open <registrationId>/getSession(id)— a browser already signed in. See Sessions.- The app’s ongoing mail — receipts, notifications, password resets — keeps arriving in the account’s inbox. Read it like any other message.
Next steps
Human takeover
The live view, the ~10-minute hold, and resuming a blocked signup.
Sessions
Hand the new account to your automation as a CDP URL or
storageState.Acceptable use
What we ask before you point a registration run at someone else’s site.
Connect an account you own
The lower-risk path when the account can exist already.
