Skip to main content
FlexOrch supports two authentication methods: API keys and JWT tokens. JWT authentication is designed for browser-based applications and user-facing flows where you need to authenticate on behalf of an individual user rather than a service account. The FlexOrch dashboard at app.flexorch.com uses JWT authentication internally. If you are building a server-side integration, a CI/CD pipeline, or any backend service, use API Keys instead — they are simpler and do not expire.

​
How JWT authentication works

When you log in, FlexOrch returns two tokens:
  • Access token — a short-lived JWT (valid for 1 hour) that you pass with every API request.
  • Refresh token — a longer-lived token you use to obtain a new access token without requiring the user to log in again.
You pass the access token as a Bearer token in the Authorization header. When it expires, call the refresh endpoint to get a new one silently in the background.

​
Sign up

Create a new FlexOrch account programmatically by posting the user’s email and password: 
curl -X POST https://api.flexorch.com/v1/auth/signup \
  -H "Content-Type: application/json" \
  -d '{"email": "you@company.com", "password": "your_password"}'
After signup, FlexOrch sends a verification email to the provided address. The account must be verified before you can log in. Direct your user to check their inbox and click the verification link.

​
Log in

Exchange email and password for an access token and a refresh token: 
curl -X POST https://api.flexorch.com/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email": "you@company.com", "password": "your_password"}'
A successful login response: 
{
  "data": {
    "access_token": "eyJ...",
    "refresh_token": "eyJ...",
    "token_type": "bearer",
    "expires_in": 3600
  }
}
​
access_token
string
required
The JWT to include in all subsequent API requests. Valid for expires_in seconds (3600 = 1 hour).
​
refresh_token
string
required
A longer-lived token used to obtain a new access token. Store this securely — treat it like a password.
​
token_type
string
Always "bearer". Use as the scheme in the Authorization header.
​
expires_in
integer
Seconds until the access token expires. Currently 3600 (1 hour).

​
Using an access token

Pass the access token in the Authorization header with the Bearer scheme: 
curl https://api.flexorch.com/v1/usage \
  -H "Authorization: Bearer eyJ..."

​
Refreshing an access token

Access tokens expire after 1 hour. When a request returns 401 Unauthorized, use the refresh token to get a new access token without prompting the user to log in again: 
curl -X POST https://api.flexorch.com/v1/auth/refresh \
  -H "Content-Type: application/json" \
  -d '{"refresh_token": "eyJ..."}'
If the refresh token itself expires or is revoked, the user must log in again. Do not store refresh tokens in localStorage in security-sensitive applications — prefer secure, httpOnly cookies or a server-side token store.

​
API key vs JWT — which should you use?

ScenarioRecommended method
Server-to-server API integrationAPI Key
CI/CD pipeline or automation scriptAPI Key
Backend microservice calling FlexOrchAPI Key
Browser-based application (user login)JWT
Mobile app with individual user accountsJWT
Platform dashboard (app.flexorch.com)JWT (handled automatically)
In short: if your code runs on a server you control, use an API key. If individual users are logging in and making requests through a browser or app, use JWT.
You can use both methods in the same product — for example, a JWT flow for your user-facing dashboard and an API key for your backend data ingestion pipeline.