Scheduler APIs
Version: aju17f20mq
Use the reference below for request and response fields and operation-specific requirements.
Overview
Create and manage schedules that invoke HTTPS targets. A firing is a logical scheduled event and can have retry attempts. Target acceptance does not prove completion of the customer’s business operation.
Follow the operation's scope: backend sk_… calls can carry an authorized X-On-Behalf-Of beneficiary, while client pk_… calls require the configured user's JWT. Owner-cleanup operations require a beneficiary; project teardown requires a subjectless backend request. The API also permits subjectless backend context. A console JWT belongs to a separate surface. See Authentication.
Tenant context comes from the authenticated request. Client-supplied X-Tenant-Id, X-User-Id or X-Project-Id do not grant authority. The current public integration uses the default project. Do not rely on project headers for separate project, test/live or customer isolation on this API.
Authenticate deliveries using the receiver verification guide. A valid token alone does not bind an arbitrary submitted body: verify the trusted schedule, payload and delivery identity before admitting work. Pause or deletion affects pending work and cannot undo effects already dispatched. Logout does not delete a user’s schedules.
Related guide: Scheduling
JSON conventions
Requests accept snake_case or camelCase field names; responses use camelCase. Ordinary default-valued scalars and empty repeated fields can be omitted. Explicitly present optional scalars, map values and well-known JSON types follow their own presence rules: an explicit false, 0 or empty value is not universally equivalent to absence. Decode each field according to its schema. 64-bit integers use JSON strings; preserve their precision. Unknown request fields are generally discarded before validation, so a typo can silently change behavior. This is not a guarantee that arbitrary fields or future client contracts are supported. See API conventions.
Authentication
Job Lifecycle
Create, manage, pause, resume, and delete scheduled jobs. See the Scheduled Jobs guide for cron, one-shot, and recurring-interval patterns with retry and auto-pause.
- Create a scheduled job
- Get a scheduled job
- List scheduled jobs
- Update a scheduled job
- Pause a scheduled job
- Resume a scheduled job
- Delete a scheduled job
- Delete all scheduled jobs for a project
- Delete all scheduled jobs for the calling owner
Execution History
Query execution records and delivery history. See the Scheduled Jobs guide for status values, retry policy details, and response capture fields.
Server 1
Travila API
X-API-Key
API key for the configured deployment. Backend sk_… calls can use authorized on-behalf-of context; a client pk_… key requires the configured user's JWT. Owner operations and project teardown have different beneficiary requirements. Keep secret keys out of client apps.
X-On-Behalf-Of
The end user this backend call acts for. An authorized sk_… request can omit this header where the operation permits a subjectless caller. In the current public integration, that caller can operate across owners in its authenticated tenant's default project. The key does not select an independently isolated project.
Supplying this header requires users:impersonate and scopes ordinary reads and mutations to that user. create-job uses that beneficiary; a different ownerSubject is rejected. Without a beneficiary, creation requires ownerSubject in the request body.
delete-jobs-for-owner requires a beneficiary. delete-jobs-for-project requires a subjectless backend request and removes schedules across owners in the current tenant/default-project scope. Check each operation before choosing the credential context. Keep secret keys on the backend.
Authorization: Bearer
The end user's own JWT, issued by the OIDC provider configured on the publishable key. Required alongside a pk_… key, and supplies the user identity in place of X-On-Behalf-Of.
Authentication credentials
- API Key: apiKeyAuth
- API Key: onBehalfOf
- HTTP: bearerAuth
| Setting | Value |
|---|---|
| Security scheme type | apiKey |
| header parameter name | X-API-Key |
| Setting | Value |
|---|---|
| Security scheme type | apiKey |
| header parameter name | X-On-Behalf-Of |
| Setting | Value |
|---|---|
| Security scheme type | http |
| Scheme | bearer |
Operations
- Create a scheduled job —
POST /api/v1/scheduler/create-job - Get a scheduled job —
POST /api/v1/scheduler/get-job - List scheduled jobs —
POST /api/v1/scheduler/list-jobs - Update a scheduled job —
POST /api/v1/scheduler/update-job - Pause a scheduled job —
POST /api/v1/scheduler/pause-job - Resume a scheduled job —
POST /api/v1/scheduler/resume-job - Delete a scheduled job —
POST /api/v1/scheduler/delete-job - Delete all scheduled jobs for a project —
POST /api/v1/scheduler/delete-jobs-for-project - Delete all scheduled jobs for the calling owner —
POST /api/v1/scheduler/delete-jobs-for-owner - List executions for a scheduled job —
POST /api/v1/scheduler/list-executions
Document ID: DOC-API-scheduled-jobs-overview. Section identities and revisions.
| Section | Stable reference |
|---|---|
| Overview | DOC-API-scheduled-jobs-overview#overview |
| JSON conventions | DOC-API-scheduled-jobs-overview#json-conventions |
| Authentication | DOC-API-scheduled-jobs-overview#authentication |
| Job Lifecycle | DOC-API-scheduled-jobs-overview#reference-group-1 |
| Execution History | DOC-API-scheduled-jobs-overview#reference-group-2 |
| Server 1 | DOC-API-scheduled-jobs-overview#reference-server-1 |
| X-API-Key | DOC-API-scheduled-jobs-overview#authentication-apiKeyAuth |
| X-On-Behalf-Of | DOC-API-scheduled-jobs-overview#authentication-onBehalfOf |
| Authorization: Bearer | DOC-API-scheduled-jobs-overview#authentication-bearerAuth |