JWT Authorization Without Interactive Login
GET /api/authorizeByJWT.do
Obtains an API authorization code in a private deployment with JWT trust configured. It does not require a prior Bearer access_token.
URL Query Parameters
| Parameter | Description |
|---|---|
response_type |
Required; code |
client_id |
Required developer application ID |
jwt_token |
Required signed JWT carrying the developer's client_id, generated by a trusted server with the agreed claims and secret |
email |
Target email; choose one of the identity fields |
phone |
Target phone number |
babelId |
Target employee identifier |
The source permits an enterprise administrator identity when no user is supplied. Explicitly specify the intended user and verify the caller may act for them. Do not rely on this omission behavior. A signed JWT does not encrypt its payload.
Result and Next Step
The decoded jwt_token structure for the current deployment is shown below (application ID and timestamp are illustrative):
{
"duration": 60,
"payload": {"client_id": 1000000000001},
"time": 1790000000000
}The developer ID is nested in payload.client_id and is numeric in the confirmed sample. Use the same actual application ID in the client_id query parameter. time is the JWT generation time as Unix milliseconds; duration is its lifetime in seconds, 60 in the example. Specify the target user separately through the email, phone or babelId query parameter. A web-login userToken cannot substitute for this jwt_token.
On success, obtain success and the authorization code, then call Get token to obtain access_token and refresh_token. Business API requests carry the authorized user identity through Authorization: Bearer <access_token>. Here code is an authorization code, not the numeric business error field; use the response field names documented on the token page.
See API overview for claims, HS256 signing and secret configuration. Keep real credentials out of public logs and frontend code.