# Getting a token without a browser

`vatio login` is the normal route, and these paths are how it works. They are
not workspace-scoped and take no developer token — they are how you obtain one.

A custom CLI starts device authorization with
`POST /api/developer/v1/device_authorizations`. The response supplies `device_code`,
`user_code`, verification URLs, `interval`, and `expires_in`.

Open `verification_uri_complete` in the user's browser, or print it where
there is none. On that page they sign in with their email (we mail a link that
signs them in on any device, creating the account if it did not exist, and
brings them back) or with Google or GitHub, then approve the terminal — a
click no email scanner makes for them. Print the `user_code` in your
terminal: the page shows the same one, and comparing them is what replaces
typing it.

`email` is optional and legacy: older CLIs sent it, and then we mail the user
the link directly and the response carries `email_sent: true`. `vatio login`
and `vatio push` no longer send it.

`workspace` is optional: the slug of the workspace you are about to create or
push to. `vatio push` sends it, so that once the user approves, the page waits
for that workspace and then sends them to the inbox: to its **Start** page,
which waits for the push, or to its **Test** page once something is deployed.
A slug that is not valid is ignored.

Meanwhile, poll
`POST /api/developer/v1/device_authorizations/token` with `{ "device_code": "..." }` at
the supplied interval. `GET /api/developer/v1/workspaces` lists workspaces and
`POST /api/developer/v1/workspaces` creates one with `slug` and optional `name`, using the
resulting developer token.