Scheduler APIs
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
- API Key: apiKeyAuth
- API Key: onBehalfOf
- HTTP: Bearer Auth
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.
Security Scheme Type: | apiKey |
|---|---|
Header parameter name: | X-API-Key |
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.
Security Scheme Type: | apiKey |
|---|---|
Header parameter name: | X-On-Behalf-Of |
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.
Security Scheme Type: | http |
|---|---|
HTTP Authorization Scheme: | bearer |
Bearer format: | JWT |
📄️ 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.
📄️ Schedule retries and auto-pause
overview}
📄️ Signed callbacks and receiver acknowledgement
overview}
🗃️ Endpoints
10 items
🗃️ Models
4 items
Document ID: DOC-CP-scheduling-api-overview. Section identities and revisions.
| Section | Stable reference |
|---|---|
| Overview | DOC-CP-scheduling-api-overview#overview |
| JSON conventions | DOC-CP-scheduling-api-overview#json-conventions |
| Authentication | DOC-CP-scheduling-api-overview#authentication |