Repository navigation
feat: per-profile API URL with hidden --api-url on login #1486
Description
Note
TL;DR: apify login --api-url <url> stores the API, issuer and Console URLs on the profile. --profile then picks the environment. No APIFY_CLIENT_BASE_URL on every command.
Problem
- P1. The CLI cannot tell which environment a token belongs to. Tokens are opaque.
- P2. Non-production use needs
APIFY_CLIENT_BASE_URLon every command. - P3.
loginguesseslocalhost:3333from the Console URL. Staging is not covered. - P4. Device flow issuer defaults to production and is not linked to the API URL.
Proposal
- S1. Hidden
--api-urlflag onlogin, for device flow and token login. Defaulthttps://api.apify.com. - S2. Discover the issuer and Console URLs from
<api-url>/.well-known/oauth-authorization-server, which redirects to the issuer metadata. - S3. Store
apiBaseUrl,issuerandconsoleUrlon the profile. - S4. Commands use the profile's URLs.
APIFY_CLIENT_BASE_URLstill overrides them. - S5. Profile key:
- production:
userId(unchanged) - other environments:
userId@host:port, e.g.AvSUC7C6j2Vlf52Zh@localhost:3333
- production:
- S6.
auth listshows an API column only when a non-production profile exists. - S7. Remove the localhost guess in
login.
Notes
- N1. Production-only users see no change: same keys, no new fields, no migration.
- N2. A URL that normalizes to
https://api.apify.comcounts as production. - N3. Accept
httpsonly, plushttpforlocalhostand127.0.0.1. - N4. If discovery fails, token login still works. Device flow stops with an error.
- N5. Check that
:is legal in keyring account names on macOS, libsecret and Windows. If not, use another separator. - N6.
apify runpassesAPIFY_API_BASE_URLto the Actor. - N7. This reverses the auth.json v2 #1419 decision against per-profile URLs. The use case is several environments with
--profile.
Related
- feat: log in through OAuth 2.0 device code by default #1402 (device flow)
- Stage-4: Login - Device flow multi account support #1385 (Stage-4)
- auth.json v2 #1419 (auth.json v2)
- Centralize hardcoded Apify domains (console / api / docs) behind a single source of truth (URL builder / registry) #1214 (one place for Apify domains)
🤖 Generated with Claude Code
Activity
l2ysho commentedon Oct 9, 2026
@DaveHanns @patrikbraborec what do you say about this? it is not big deal to do and it should help people who use different environments (staging, localhost)
patrikbraborec commentedon Oct 12, 2026
Yeah, not 100% about the flag name, but otherwise it sounds good. We could also somehow coordinate this with local runtime (@Pijukatel), if it is possible -- but maybe these are different things. Anyway, I was thinking that will local runtime, you would just use this time of command to either:
Pijukatel commentedon Oct 12, 2026
I am not sure what the end goal is here, but from a local runtime point of view, I do not see any benefit so far. When redirecting the CLI to the local runtime (due to env vars being set, or through
apify runtime connect), the local runtime just takes the tokenapify login -t ...or uses whatever was already logged in, it can be valid token for real platform, or fake token as well. Maybe I am missing the point here?Anyway, from my point of view, at least the first two problems are correct behavior: