Pick a base URL, then pick how much of the transaction the terminal owns.
The connectivity model determines the base URL and the network posture of your integration. Every endpoint in this reference works against both Local Connected and Cloud base URLs — the schema, status codes, and field semantics are identical.
Connectivity models
Local Connected
~8 ms
POS and terminal share a LAN. Lowest latency, fully offline-capable.
Cloud Relay
~90 ms
POS routes through Atlas to the terminal over a persistent tunnel.
Local Embedded
~2 ms
Kernel runs in-process inside the merchant app. Native, not REST.
LOCALHTTPhttp://terminal:8443
LOCALWSws://terminal:8443/v1/session
CLOUDHTTPhttps://api.atlas-softpos.com
CLOUDWSwss://api.atlas-softpos.com/v1/session
Orchestrated vs Granular
Two ways to drive a transaction. Orchestrated keeps your POS out of the acquirer leg entirely; granular puts your POS in the middle so you can route authorizations yourself.
Orchestrated
2 calls from your POS
The terminal owns the acquirer leg. Your POS just makes one call and waits for the result.
Granular
6 calls — POS in the middle
Your POS routes the issuer authorization itself. Use this for multi-acquirer routing or store-and-forward.
The two axes are independent — any connectivity model works with either operational mode. A common production pattern is cloud relay + orchestrated for the simplest possible POS integration, or local connected + granular when you need multi-acquirer routing inside a retail store.