Skip to content
Console
Menu

Getting Started

Authentication

KV Store

Targets

The receiver's side of a fire: what it is sent, what it answers, and what a refusal leaves behind.

A [[compute.schedules]] row names a service of the project and a path that starts with /, not a URL. Each fire is a signed request to that path, so the receiver can tell a fire from anything else that knows the address. A [[jobs]] row with a schedule needs no receiver: a fire starts the Job's run.

#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 the row's retry policy, 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. One instant starts at most one request that counts, so a handler can rely on (schedule, intended time) to deduplicate.

#Reading the outcome

Shell
curl "https://api.sylphx.com/v1/orgs/acme/projects/shop/envs/production/schedules/$SCHEDULE" \
  -H "Authorization: Bearer $SYLPHX_API_KEY"

The Schedule's status says what the most recent fire did, and the refusals it collected. Schedules is what the tick states mean.