Signing in

link#

pinecall link [--org <slug>] [--gateway <url>]

This project's folder, tied to one of your orgs. Run in the project's folder: it signs this machine in through the browser when it is not (login, the same dance), lists your orgs (GET /v1/login/orgs), asks which one this project is — --org names it — and mints your key there (POST /v1/login/org), unless it is the org this machine is signed in to, whose key it already holds. The key goes into ./.env as PINECALL_KEY, and PINECALL_URL beside it when the gateway is not https://cloud.pinecall.io; every other line of the file is left as it was. That one key opens both environments at that one gateway — the sandbox without --prod, production with it — and nothing else is written or derived (above).

~/clinica $ pinecall link --org clinica
▸ clinica · PINECALL_KEY written to .env
git would commit .env: add it to .gitignore before a commit carries your key

The last line is said every time until the project's .gitignore names .env: a key committed is a key published. Every verb run in this folder, or under it, reads the key from there; a project of another org is another folder, linked on its own. --gateway names another gateway than the one this machine last signed in to. A server does not link: it runs on a server's token from the console's Tokens screen, kept in its secrets (Production).

login#

pinecall login [gateway-url]

login prints a link and opens it. You sign in there — in a browser, where a password belongs, where the browser autofills it and a password manager holds it — and the page hands this terminal a key of its own: minted for you, labelled as this machine, revoked on its own from the Tokens screen. Nothing types a password into a shell, and the day your org signs in with Google this verb does not change.

$ pinecall login
gateway  https://cloud.pinecall.io   (the default — `pinecall login <url>` for your own)

open this to sign in:
https://cloud.pinecall.io/cli?c=cli_…

waiting…
signed in to https://cloud.pinecall.io as Ana García

It signs the machine in, and no verb runs on that. The key is proved at /v1/whoami and kept in ~/.pinecall/session.json; what a project runs on is the key link mints from it into the project's .env. link signs in on its own when it has to, so this is rarely typed. With no URL it is https://cloud.pinecall.io, and it says so above the link, so a person who meant their own platform sees the assumption before anything is kept. The URL is the one gateway's, and the key it leaves opens both of its environments; the sandbox keeps no password of its own. The word in the link dies in ten minutes and on first collection; a terminal with no browser prints the same link and you open it from wherever you are. A server has no login at all.

whoami#

pinecall whoami [--prod]

The one endpoint: PINECALL_URL, with the key from the environment or the project's .env, on one line with where the key came from; under it what the gateway says the key is in the environment asked — the sandbox, or production with --prod: the org (its slug, or its id when the gateway carries none), the key's id, the environment, the label it was issued under, and whether the key may act in production — your switch, an admin's always, or a production server token; and under that which environments the key opens there: a person's key both, the sandbox without --prod and production with it while the switch is on; a server's token the one its prefix names. The exit code is the gateway's answer: 0 when it said who the key is, 1 when it refused, in its words. The key itself is neither printed nor sent anywhere else.

$ pinecall whoami
gateway https://cloud.pinecall.io · key from .env · sandbox
  org clinica · key k_4f2a1d9c66b30e17 · sandbox · ana-macbook · production: yes
  a person's key: the sandbox without --prod, production with it