API Authentication

Most product API operations require a JWT in the standard HTTP bearer header:

Authorization: Bearer <token>

The installed OpenAPI operation records whether authentication is required and which product scope applies. A valid token is not sufficient when its roles or tenant membership do not authorize the requested operation.

Use TLS

LyftData serves HTTPS by default. Install a trusted certificate for production automation. Use insecure certificate handling only for a controlled evaluation with the default self-signed certificate; never make it a permanent script default.

See Networking and TLS for certificate setup and verification.

Obtain and handle a token

Use an administrator-approved user or API-key workflow to issue a time-bounded JWT with only the required roles and tenant access. The shipped CLI can issue a user token without placing the password in process arguments:

lyftdata users issue automation-user \
  --password-stdin \
  --ttl 30m

Provide the password on standard input when prompted or through a protected secret-delivery mechanism. Capture the returned JWT in your automation’s secret store, then expose it only to the process making the request.

For an issued API key, exchange the key for a JWT without placing the key in the process list:

lyftdata api-key auth -

Provide the API key on standard input. Direct API clients can use POST /api/tokens/create/api for the same exchange. Normal authenticated requests send the returned JWT as a bearer token; they do not send the raw API key.

Avoid:

• passwords or tokens in command history;
• tokens in URLs or query strings unless a documented streaming handshake explicitly requires it;
• long-lived administrator tokens for read-only jobs;
• logging request headers; and
• committing .env files containing tokens.

Make an authenticated request

curl --fail --silent --show-error \
  "https://lyftdata.example.com/api/auth/me" \
  -H "Authorization: Bearer ${LYFTDATA_JWT}" \
  -H "Accept: application/json"

GET /api/auth/me is a useful first check because it reports the authenticated identity. A 401 Unauthorized response indicates missing, invalid, or expired authentication. A 403 Forbidden response indicates that the identity is known but lacks the required role, scope, tenant access, edition, or capability.

Apply least privilege

Separate human administration from unattended automation. Give an automation identity only the read or write roles and tenant memberships needed for its task. Use different credentials for:

• read-only inventory and health collection;
• deployment mutations;
• credential or secret administration; and
• worker bootstrap.

Worker API keys and auto-enrollment secrets authenticate workers; do not reuse them as general administrator credentials. See Worker authentication.

Rotate and revoke

Use short token lifetimes. Rotate the underlying password or API key according to your policy and revoke it immediately after suspected exposure. Removing a token from one script does not revoke other issued tokens, and deleting a Credential Manager record does not revoke a product user session.