HTTP targets

On the surface that runs schedules today, a fire lands on an HTTP target: a signed request to an https URL, in the method the target states, so the receiver can tell a fire from anything else that knows the address. The declared schedules collection does not have HTTP targets — its Schedule names the Workflow to start in the same environment — so this page is about the Compute API's target.

#A target states four things

curl -X POST "https://api.compute.sylphx.com/v1/schedules" \
  -H "Authorization: Bearer $SYLPHX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"idempotencyKey":"targets-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}}'

url must be https and signed must be true. A target that is neither is refused when the schedule is validated rather than when the first fire lands, which is the difference between a create that fails in front of you and a schedule that quietly never delivers. The signature is the receiver's check: a fire arrives from the platform, and a request that merely knows the address is not one.

#What the receiver answers

The receiver's whole job is a status. A 2xx answer records the tick as succeeded. Anything else records it as dead_lettered, so a handler that refuses — a payload it cannot use, a downstream that is down — leaves a dead letter beside the tick rather than a fire that looks delivered.

Retries belong to the platform, bounded by retry.maxAttempts, so the handler does not have to retry on its own. A handler that wants a fire retried should answer with a refusal and let the platform do it, rather than holding the request open.

#An easy first receiver

A receiver that answers 200 and ignores the body is enough to watch a schedule fire end to end before you run one of your own. The run lines on this page and on the quickstart point at the public one-click route (https://sylphx.com/unsubscribe/one-click), which answers 200 to any POST.

#Reading the outcome

GET /v1/schedules/{id} answers the schedule's own record, and both sides of the fire are in it:

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

lastTick says what the most recent fire did, and deadLetters collects the refusals. Schedules is what the tick states mean.