Connect an account you own

​

Connect an account

sente connect https://app.example.com/login --identity <id> \
  --username you@company.com --password '...' \
  --totp-seed JBSWY3DPEHPK3PXP   # optional: base32 or an otpauth:// URI

const { connection, run } = await sente.connections.connect({
  identityId,
  appUrl: "https://app.example.com/login",
  credentials: { username: "you@company.com", password: "...", totpSeed: "JBSWY3DPEHPK3PXP" },
});
const done = await sente.runs.waitForRun(run.id);
// done.status: "completed" | "blocked" | "failed"

res = sente.connections.connect(
    identity_id=identity_id,
    app_url="https://app.example.com/login",
    username="you@company.com",
    password="...",
    totp_seed="JBSWY3DPEHPK3PXP",  # optional
)
done = sente.runs.wait_for_run(res.run.id)

​

Two-factor authentication

• Authenticator app (TOTP) — autonomous. Pass the authenticator secret as totpSeed (the base32 string behind a QR code’s “can’t scan?” link, or a full otpauth:// URI). Sente vaults it encrypted and computes the 30-second RFC-6238 code server-side at login and every re-login. The seed never reaches any model — the server derives the code and injects it.
• Email or SMS code — needs a human. The code goes to your inbox or phone, not the identity’s, so Sente cannot read it. The run blocks with code MFA_REQUIRED and an interactive live-view URL. A person opens the live view, enters the code, and resumes the run. Two ways to avoid the human step on future logins: use TOTP on the account, or repoint the account’s notification email to the Sente identity’s address and pass verifyToIdentity: true when connecting (raw POST /v1/connections only today — not yet exposed in the SDKs or CLI), so Sente fetches the code from the inbox itself.
• TOTP prompt but no seed supplied — the run blocks with TOTP_REQUIRED; a human enters a code in the live view, then resumes.

​

What can’t be connected

• SSO-only accounts (Google/Microsoft/Okta sign-in, passkeys). There is no password to vault, so there is nothing Sente can re-login with. Not supported.
• SMS-2FA accounts connect, but every login that triggers an SMS code needs a human in the live view — Sente has no phone number for the account.

​

Credentials are write-only

​

Revoke vs. delete

sente connection revoke <connectionId>   # disable; vault kept — reconnect re-enables
sente connection delete <connectionId>   # revoke AND purge the stored credentials + seed

await sente.connections.revoke(connection.id); // disable, keep vault
await sente.connections.delete(connection.id); // revoke + purge — Sente holds nothing afterward

sente.connections.revoke(res.connection.id)
sente.connections.delete(res.connection.id)

• Revoke (POST /v1/connections/:id/revoke) disables the connection: sessions and logins are refused, but the vaulted secrets are kept — Sente holds them, unused. Connecting the app again re-enables it (the connect call always requires and re-vaults credentials).
• Delete (DELETE /v1/connections/:id) revokes and purges the vaulted password and TOTP seed. Use it for offboarding. Note that Sente holds no credentials after a delete — but the account’s password at the app is unchanged; rotate it there if you want certainty.

​

Recommended practice

• Connect a scoped account, not your admin login. If the app supports member accounts, service accounts, or restricted roles, create one with the least privilege the agent needs and connect that.
• Rotate credentials by re-supplying them. After changing the password at the app, either connect again (a POST /v1/connections on an existing connection re-vaults fresh credentials) or PUT the new values: sente.registrations.setCredentials(id, { password }) / registrations.set_credentials(id, password=...). The PUT writes the vault only — it does not change the password at the app.
• List what’s connected with sente connections / sente.connections.list() and prune connections you no longer use.

​

If a login breaks later