Jobs quickstart

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

#1. Create the schedule

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:

{
  "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.

#2. Read it back

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 is what the tick states mean.

#3. Delete it

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.