Skip to main content
Register creates a new account at a third-party app. Sente drives a real browser through the signup form, completes email verification from the account’s own inbox — the code or link is extracted server-side and applied inside the run, you never touch it — and leaves you with a durable account: credentials in the vault, session persisted, ready to re-use. If the account can exist already, Connect it instead. Connect is the safer path — no terms question, no fraud wall, no CAPTCHA at the door. Register is for the case where there is genuinely no account yet and the target’s terms allow one to be created this way.
Register only where the target’s terms of service permit automated account creation. Where the terms require a person to form the agreement, use confirmBeforeSubmit so a human clicks the final submit themselves — and where automated form-filling is prohibited outright, don’t point a run at the site at all. See Acceptable use.

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.com is the canonical example — blocks with PHONE_REQUIRED and 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_REQUIRED and 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.
The scope that works well: apps where signup is a form plus an emailed code or link, and whose terms permit it.
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/signupexample@sente.run). Credentials are optional too: supply a username and password, or let Sente derive a username and generate a strong password.
The generated password is 20 characters, mixed classes, with ambiguous glyphs (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

Pass confirmBeforeSubmit: 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.
A blocked run holds for about 10 minutes, then fails with BLOCKED_TIMEOUT. Confirm-before-submit is useless if nobody is watching — wire the run.blocked webhook or run sente watch so the page reaches a person inside the hold.

Calling register twice

Registration is idempotent per (identity, app origin), so a retry is safe:
This holds per identity. Calling register twice with no identityId provisions a second identity and signs up a second time. Keep the returned registration.id (or pass identityId) when you mean “the account I already made”.

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.