FAQ

1. Can a single machine account hold multiple valid access/refresh token pairs at the same time?

No. Each time you call POST /v2/auth/login, any previously issued access tokens for that account are invalidated. Sessions do not coexist – only the most recent token pair is valid.

2. What happens when I refresh a token via GET /v2/auth/refresh/{token}?

All active sessions of the same account are invalidated. This includes not only the refresh token being used but also any other token pairs associated with that account.

3. Are there rate limits for the authentication endpoints?

Yes. We recommend not exceeding the following limits:

Endpoint	Recommended limit
/v2/auth/login	6 requests per minute
/v2/auth/refresh/{token}	1 request per minute
/v2/api/account	12 requests per minute
/v2/api/customer	12 requests per minute
/v2/api/billing	12 requests per minute
General API endpoints	20 requests per minute

Note: Exceeding these limits will not immediately return a 429 response. If excessive usage continues and impacts system load, we will notify you. If no action is taken, hard limits may be enforced – at which point you will start receiving 429 status codes.

4. What are the actual token TTLs in production?

Token	Production TTL
Access token	~5 minutes
Refresh token	~15 minutes

The documentation mentions longer values (1 hour / 30 days), but the actual TTLs returned in accessTtl and refreshTtl fields should be trusted. Recommended flow: Perform login once, then refresh every 5 minutes using the refresh token.

5. Can a machine account use two-factor authentication (2FA)?

No, not at this time. If 2FA is enabled on a machine account, you will be required to provide a TOTP code on every authentication attempt. Since there is no documented non-interactive TOTP flow for machine accounts, we recommend keeping 2FA disabled for such accounts.

6. Should I store token pairs per instance or use centralized storage?

That depends on your architecture:

• Because concurrent sessions are not supported and refreshing invalidates all sessions, per‑instance token pairs may lead to frequent invalidations.
• If your autoscaling environment (e.g., Google Cloud Run) runs multiple backend instances, consider centralizing token storage with distributed locking to avoid race conditions and repeated logins.