Request headers
The headers and signed token the scheduler sends with every call to your target.
Headers we add
Every call carries these headers, as well as the ones you set on the job.
| Header | Holds |
|---|---|
X-Scheduler-JobId | The job’s ID |
X-Scheduler-JobName | The job’s name |
X-Scheduler-RunId | The run’s ID |
X-Scheduler-Attempt | The attempt number, from 1 |
X-Scheduler-ScheduleTime | When the run was due, in RFC 3339. The same for every attempt in a run |
Use X-Scheduler-JobId and X-Scheduler-ScheduleTime together to recognise a run you have already handled. See Repeated calls.
Headers you cannot set
The scheduler sets these itself, so a job cannot:
Host,Content-Length,Transfer-Encoding,Connection, andUser-Agent- Any header starting with
X-Scheduler- Authorization, when signing is on
Signed token
With signing on, every call carries a token in the Authorization header:
Authorization: Bearer <token>The token is a JSON Web Token, signed with RS256. A new one is made for each attempt, and it expires 10 minutes later.
| Claim | Holds |
|---|---|
iss | https://scheduler-api.digitospace.com |
aud | The job’s audience: the target URL without its query, or the job’s signing.audience |
sub | projects/{project}/jobs/{job}, the job that made the call |
iat | When the token was made |
nbf | 30 seconds before it was made, to allow for clocks that differ |
exp | When the token expires, 10 minutes after it was made |
jti | The run’s ID and the attempt number, such as 01m3c081dbf3j55x7hsa7wc1yj.2 |
project_id | The project’s ID |
job_id | The job’s ID |
run_id | The run’s ID |
The public keys are at https://scheduler-api.digitospace.com/.well-known/jwks.json, and the discovery document is at https://scheduler-api.digitospace.com/.well-known/openid-configuration. See Verify calls to your target.
Last updated