Cron jobs
Cron jobs run scheduled HTTP requests that repeat at regular intervals. They're useful in three typical scenarios:
- Refreshing tokens that your REST API tools use through
periodicAuth. - Keeping caches warm or triggering health pings to your services.
- Running periodic loads or any scheduled side-effect.
Each run is logged with its request and response, so you can audit what happened in every execution.
To start, click "Create cron job". The wizard changes depending on the type you choose: an auth cron has 6 steps (it includes the Result step), while a generic one has 5 steps.
Step 1: Configuration
Give it a name and an interval. The type decides how each run's result is used.
| Type | What it's for |
|---|---|
| Auth (refreshes tokens) | Periodically refreshes an authentication token and stores the latest value so your tools can use it via periodicAuth. |
| Generic (scheduled request) | Runs a scheduled HTTP request and stores the response. Useful for keeping caches warm, health pings, or periodic loads. |
| Field | Description |
|---|---|
| Name | Unique in the workspace. For auth crons, this is the name your tools reference with periodicAuth.name. |
| Description | A short note about what the cron does (optional). |
| Interval (hours) | How often it runs, in hours. Between 1 and 168 (one week). The scheduler checks every 5 minutes. |
The auth type is exactly what connects to the Periodic auth option in the Advanced section of a REST API : there you select this cron by its name to inject the refreshed token into your requests.
Step 2: Request
Define the HTTP request the cron will run: method, URL, headers, body, and authentication. Path variables (:name) are detected automatically.
It's the same builder you use in REST API, with the Params, Authorization, Headers, Body, and Settings tabs.
Step 3: Result (auth type only)
Indicate where the token is within the JSON your endpoint returns. This step only appears for auth-type crons.
| Field | Description |
|---|---|
| Result path | The path to the token using dot notation. For example: access_token, data.token, or tokens[0].value. |
Your tools and scripts inject this token with periodicAuth: { name: "...", key: "Authorization" }. The latest extracted value is stored in cron/{id}/results.
Step 4: When
Define when the cron is allowed to run. By default it runs on its interval, 24/7, with no cap.
Enable "Execution rules" if you want to limit it:
| Rule | Description |
|---|---|
| Time zone | The zone in which the day and time rules are evaluated (for example, UTC). |
| Allowed days | The days of the week it can run. |
| Time window | By default it runs 24h on the allowed days; enable "Restrict" to narrow it to a range of hours. |
| Execution limits | Max per day and Max per month to cap the number of runs. The counter resets when the day / month changes in the configured time zone. |
Step 5: Test
Before creating the cron, you can run the configured request and see the response in real time against your endpoint. Nothing is persisted yet.
Run the test whenever you can: it's the fastest way to catch a mistyped URL or wrong authentication before the cron starts running on its own.
When you're satisfied, click "Create cron".
Step 6: Done
The cron is created. The first run will happen within the configured interval at most (for example, within 12h at most if that's your interval); if you don't want to wait, you can run it manually from the detail view.
From here you can "Back to list" or go to "View details" of the newly created cron.
Remember that a generic cron has one fewer step (it doesn't include Result), so for that type Test and Done are steps 4 and 5.