Skip to main content

Pushing Data In

eConnect is usually fed by its own collectors, but any module will take data from your software instead — or as well. A ticketing system can push TITO redemptions, a table-management system can push ratings, a till that eConnect has no driver for can push transactions, and an edge detector can push its own detections.

Data you push is ordinary eConnect data from the moment it lands: it shows in grids, feeds dashboards and landing pages, raises alerts if a rule matches, is covered by retention and audit, and can be asked about in plain language through Ace.

How ingress works​

Where to push what​

What you haveModuleEndpoint
Table ratings, player sessionsCasinoPOST casino-connect/plugins/{id}/ratings
TITO tickets — issue, redeem, voidCasinoPOST casino-connect/plugins/{id}/tito-tickets
Till transactions, voids, discountsPoint of SalePOST pos/plugins/{id}/events
Face detections from your own engineObject AnalyticsPOST oa/plugins/{id}/subject-detections
Licence plate reads from your own LPRObject AnalyticsPOST oa/plugins/{id}/license-plate-detections
Baccarat hands and shoe eventsBaccaratPOST casino-baccarat/plugins/{id}/events

Rules that apply to all of them​

Batch. Most modules offer a batch endpoint beside the single-record one. One request carrying five hundred rows costs far less than five hundred requests — for your process, for the server, and for the database behind it.

Send UTC, and send the real time. dataTimeStamp is the moment the thing happened, not the moment you got round to sending it. Events arriving with send-time stamps make every time-based query, dashboard and alert wrong in a way that is hard to spot later.

Be idempotent on your side. The endpoints do not de-duplicate for you. Keep a high-water mark of what you have sent, and on a retry resend only what you are unsure about. A duplicate rating is a duplicate rating.

Expect 400, and read it. Validation failures come back as RFC 9457 problem documents whose detail names the field. Log the whole body when a push fails; it is the difference between a five-minute fix and an afternoon.

One service account, least privilege. Create a dedicated eConnect user for the integration and grant it only the keys its module needs. See Permission Keys.

A worked loop​

const BASE = 'https://your-server/api/v2';

class EcClient {
#tokens = null;

async signIn() {
const res = await fetch(`${BASE}/auth/login`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ userName: process.env.EC_USER, password: process.env.EC_PASSWORD }),
});
if (!res.ok) throw new Error(`sign-in failed: ${res.status}`);
this.#tokens = await res.json();
}

async #refresh() {
const res = await fetch(`${BASE}/auth/token/refresh`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ refreshToken: this.#tokens.refreshToken }),
});
// A refused refresh means the session is gone, or permissions changed under us.
if (!res.ok) return this.signIn();
this.#tokens = await res.json();
}

async send(path, body) {
for (let attempt = 0; attempt < 2; attempt++) {
const res = await fetch(`${BASE}${path}`, {
method: 'POST',
headers: {
Authorization: `Bearer ${this.#tokens.accessToken}`,
'Content-Type': 'application/json',
},
body: JSON.stringify(body),
});

// 401 is the expected way to learn the token aged out, or that an administrator changed
// this account's permissions — refresh once and try the same batch again.
if (res.status === 401 && attempt === 0) {
await this.#refresh();
continue;
}
if (!res.ok) throw new Error(`${res.status}: ${await res.text()}`);
return res.json();
}
}
}

Next​

Pick the module you are feeding: