Menu
Platform
AI
App store purchases
Credits
Database
Flags
Generated Assets
Monitoring
Notifications
Organizations
Payments
- Payments
- Payments quickstart
- Checkout policies
- Checkout sessions
- Customer subscriptions
- Entitlement grants
- Exchange rates
- Licence keys
- Licence tokens
- Merchant accounts
- Portal sessions
- Price catalogs
- Revenue
- Revenue facts
- Revenue sources
- Tax threshold statuses
- Usage events
- Usage invoices
- Usage meter prices
- Usage meters
- Usage reservations
- Usage settings
- Usage tiers
Sandboxes
Webhooks
Getting Started
Authentication
KV Store
Deploy & Infrastructure
Reference
On this page
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
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.