eConnect Core API
eConnect Core is the server at the centre of an eConnect installation: it holds users, permissions and settings, and it hosts the plugins — point of sale, casino, baccarat, object analytics, cases, cameras — that hold the operational data.
The v2 API is how your own software talks to it. It is a conventional REST surface with JSON bodies and JWT bearer authentication, generated from the same service contracts the eConnect client runs on, which means an integration is never working against a second-class copy of the product.
What you can build
| You want to | Start at |
|---|---|
| Push data in — ratings, TITO tickets, POS transactions, detections | Pushing Data In |
| Read data out — events, subjects, cases, statistics | API Reference |
| Automate administration — users, permissions, logical groups | Core |
| Generate a typed client from the schema | OpenAPI schema |
| Understand the shape of it first | Architecture |
| See the whole surface before picking a module | The whole API |
The one thing to understand first
Almost every endpoint belongs to a plugin instance, not to the server. A deployment can run two point-of-sale instances, three camera instances and one casino instance, each with its own data, and the route carries the instance you mean:
POST /api/v2/casino-connect/plugins/{pluginInstalledId}/ratings
└──────────┬──────────┘
which casino instance this rating belongs to
So an integration always does the same three things: get a token, list the plugins to find the instance id, then call the module. That sequence is Getting Started, and it is about fifteen lines of code.
What this API is not
- It is not a second data model. The endpoints are generated from the service contracts the eConnect client itself calls, so what you can read and write is what an operator can read and write — no more, and no less.
- It is not a way around permissions. A token carries a session, and the server authorises every call against that user's permission keys. A service account sees exactly what you granted it.
- It is not versionless. v1 (SOAP and the older REST surface) still exists and is unchanged. New integrations should use v2.
Where to go next
- Getting Started — base URL, a token, and your first call, with code you can paste.
- Architecture — how sign-in, plugin discovery, permissions, errors and paging work, with diagrams.
- The whole API — all fourteen modules, their sizes and the patterns they share, on one page.
- OpenAPI schema — download the document for 11.0 and generate a client in your language.
- Pushing Data In — the ingress endpoints, one page per module, with payloads.
- API Reference — every endpoint, by module.