Skip to main content

​
What is a Signal?

A signal is the atomic unit of SchedKit. Everything is a signal — a GPS ping, a photo from the field, a text note, a human pressing ALERT. Signals are typed, org-scoped, and optionally geo-tagged. They flow in real time via SSE and fan out to push notifications, webhooks, and physical devices.

​
Signal types

TypeDescriptionPersisted
beaconPeriodic GPS ping from an active operatorNo — broadcast only
capturePhoto or image with locationYes
noteText note, optional coordinatesYes
checkinManual confirmation of presence at locationYes
alertHigh-priority — pushes to all org members immediatelyYes
beacon signals skip the database for performance. They are broadcast-only and do not appear in GET /v1/signals. All other types are persisted and queryable.

​
Org scoping

Every signal is scoped to an organization. When you POST a signal, SchedKit resolves your primary org automatically. Pass org_id explicitly to target a different org.

​
Live stream

Subscribe to your org’s signal feed via SSE: 
curl -N https://schedkit.net/v1/signals/stream \
  -H "x-api-key: $SCHEDKIT_KEY"
Events are newline-delimited data: payloads: 
data: {"type":"connected","org_ids":[3]}

data: {"type":"signal.beacon","payload":{"user_id":42,"lat":35.4676,"lng":-97.5164,...}}

data: {"type":"signal.alert","payload":{"Id":7,"note":"Unit 3 unresponsive",...}}

​
Beacon fast-path

beacon type signals bypass NocoDB writes entirely — they are constructed in memory and broadcast directly to all connected SSE clients. This supports high-frequency pinging (every 30s per device) at scale without DB bottlenecks.

API Reference → Signals

Full endpoint docs for POST, GET, DELETE, and SSE stream.