#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.