---
title: Jobs quickstart
description: Create a Schedule on the Compute API, take the wake receipt, read the schedule back and delete it.
type: tutorial
product: jobs
summary: A schedule created, read and deleted, with the receipt that says the wake was placed.
updated: 2026-09-28
order: 1
---

Every run line on this page calls the Sylphx Compute API, which is where
schedules run today. Nothing here goes through the one API.

<Prerequisites
	items={[
		'An account, and a project with an environment — see the platform start page',
		'A Sylphx Access key the Compute API accepts; schedules take the workflows:read and workflows:write scopes',
		'An https endpoint that answers a POST — the run lines below use the public one-click route, which always answers 200',
	]}
/>

## 1. Create the schedule

```bash
curl -X POST "https://api.compute.sylphx.com/v1/schedules" \
  -H "Authorization: Bearer $SYLPHX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"idempotencyKey":"quickstart-1","spec":{"calendar":{"kind":"rate","everySeconds":30,"timezone":"UTC"},"overlap":"skip","catchUp":"skip","target":{"kind":"http","method":"POST","url":"https://sylphx.com/unsubscribe/one-click","signed":true},"retry":{"maxAttempts":3},"pause":false}}'
```

Read out of the spec:

- `calendar` — `kind` `"rate"` with `everySeconds` is a fixed period, from 1
  to 31536000 seconds, and `timezone` is the zone the calendar is read in. A
  rate's first due time is one interval away, so this schedule first fires 30
  seconds from now.
- `overlap` and `catchUp` — what a fire does while the previous Run is still
  running, and what becomes of a fire nobody delivered. `skip` is the
  conservative choice for both.
- `target` — where the fire lands: `kind` `"http"`, an https `url`, the
  `method`, and `signed: true`, which is required.
- `retry.maxAttempts` — how many times a fire is retried before it is
  recorded as refused.
- `pause` — `false` means the fires are live.

The answer names the schedule, the operation that placed its first wake, and
the authority that answered:

```json
{
  "schedule": {"identity": {"resourceId": "…", "revision": "…"}},
  "operation": {"state": "succeeded"},
  "authority": "compute"
}
```

Trimmed to the fields this page reads. Accept the create only when
`operation.state` is `succeeded`: that is the receipt that the clock wake was
placed, and the schedule's own `identity.resourceId` is what the next two
steps address.

<Callout tone="warning" title="A create that is not `succeeded` scheduled nothing">
When the platform cannot place the wake, the create answers `202` with
`operation.state` not `succeeded` and an `errorCode` of
`platform_place_cell_wake_unavailable`. Nothing fires, and the code is the
reason.
</Callout>

## 2. Read it back

```bash
curl "https://api.compute.sylphx.com/v1/schedules/$SCHEDULE_ID" \
  -H "Authorization: Bearer $SYLPHX_API_KEY"
```

`$SCHEDULE_ID` is the `identity.resourceId` the create answered with. What
comes back is the schedule's own state: `identity` — `resourceId` and
`revision` — the `spec` you wrote, `lastTick`, and `deadLetters`.

`lastTick` is the read-back for a fire, so ask again after the first interval
has passed. [Schedules](/docs/jobs/schedules) is what the tick states mean.

## 3. Delete it

```bash
curl -X DELETE "https://api.compute.sylphx.com/v1/schedules/$SCHEDULE_ID" \
  -H "Authorization: Bearer $SYLPHX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"expectedRevision":"'$REVISION'","idempotencyKey":"quickstart-delete-1"}'
```

`$REVISION` is the `identity.revision` from the read just before. The delete
is revision-fenced: a tick between your read and your delete moves the
revision, and the delete is refused with a conflict rather than removing a
schedule you did not read. Read again, and delete with the revision you just
read. `idempotencyKey` is what keeps a retried delete one delete rather than
two.

## Where the CLI fits

The CLI reference prints these calls in the one-API form —
`sylphx workflows schedules create --parent … --spec.workflow …` and the rest
of the `schedules` commands. That is the declared collection's form; the
surface that runs today is the Compute API the run lines above call.

<RelatedDocs
	links={[
		{
			href: '/docs/jobs/schedules',
			label: 'Schedules',
			description: 'The identity rule, the tick states, and the revision fence.',
		},
		{
			href: '/docs/jobs/targets',
			label: 'HTTP targets',
			description: 'What the receiver of a fire gets, and what it answers.',
		},
		{
			href: '/docs/api/schedules',
			label: 'The schedules collection',
			description: 'The Schedule Resource as declared, with every method and example.',
		},
	]}
/>