Integration flow
| Step | When to call | Operation |
|---|---|---|
| Activate | Once, at installation | POST /device/v1/activations |
| Send a heartbeat | On a regular interval | POST /device/v1/heartbeats |
| Check applications | Between heartbeats, on the terminal's own schedule | GET /device/v1/applications |
| Download a release | When an assigned release is not installed | POST /device/v1/artifact-downloads |
| Check parameters | Between heartbeats, on the terminal's own schedule | GET /device/v1/parameters |
| Download a parameter document | When a document's digest differs from the one applied | GET /device/v1/parameters/{application_id} |
| Report a transaction | After each transaction | POST /device/v1/transactions |
| Report hourly totals | Once an hour | POST /device/v1/transaction-metrics |
| Report events | As they occur, in batches | POST /device/v1/events |
| Send logs | Continuously, in batches | POST /device/v1/telemetry/v1/logs (see Telemetry) |
Every heartbeat response also lists the applications and parameters the terminal should hold, so a terminal that only sends heartbeats still receives every change. The two list operations let it pick up a change sooner, without sending a full heartbeat.