Your system keeps the commercial data; the platform runs the technical data.
Subscribers, contracts, tariffs and invoices stay in your system. Meters, readings, events, work orders and depots live in the platform. There is one shared key: the usage point number. That split is why no software change is needed in your billing system.
Meters, readings, events, work orders, depots, calibration.
Subscribers, contracts, tariffs, invoices, collection.
Three contracts, zero changes.
However you receive meter data today — reader route file, index file, disconnection list — the platform steps into the place of those same interfaces.
Master data, inbound
Subscriber number, usage point number, address, subscription status, meter serial. Dropped into your SFTP box as a daily full or delta file; the platform picks it up overnight and reports back with a result file. A missing row is never deleted, only flagged.
Period index, outbound
At period close, validated index values are produced in your own handheld-terminal file format. To the billing system it looks like another reader has been round. A company that prefers it can pull the same data through the API.
Order and result
The disconnection/reconnection list arrives at the platform, the valve command goes out under dual approval, and the result comes back as a field report in the same format. For larger companies there is a REST equivalent and webhooks.
By subscriber or usage point number, in a single call.
Your subscriber app or billing system reaches meter data by subscriber or usage point number. Identity: a per-company integration client (OAuth2 client credentials), scoped permissions, an IP allowlist and optional mTLS. Every call is written to the usage ledger.
| Endpoint | What it returns |
|---|---|
GET /v1/subscribers/{aboneNo}/usage-points | The subscriber's usage points and a summary of the meters fitted |
GET /v1/usage-points/{tesisatNo} | Meter status: valve, last data time, clock drift, battery, signal, calibration validity |
GET …/readings?from&to&granularity | Index and consumption; hourly, daily, monthly; measured / estimated quality flag |
GET …/events | Events and alarms, with an explanation in subscriber language |
POST …/requests | Open a request (meter check, index dispute, move); it becomes a work order and its status is tracked |
GET /v1/readings/billing?period | Period-close index values, all usage points, paged or as CSV |
PUT /v1/master-data/usage-points | Bulk master data update with a row-by-row validation report |
PUT /v1/webhooks | Valve changed, alarm, silent meter, request updated, period ready |
GET /v1/usage-points/34-KAD-0001127/readings?from=2026-08-01&to=2026-09-01&granularity=day
Authorization: Bearer eyJ…
200 { "unit": "m3", "kind": "Vm",
"items": [ { "period": "2026-08-01", "indexEnd": 12604.9, "consumption": 2.8, "quality": "MEASURED" } ] }/v1; at least 12 months of backward compatibility; errors in RFC 7807 form with a readable title. Limits: tokens 30 per minute per IP, data endpoints 600 per minute per client (120 in the sandbox); 429 when exceeded. Your company administrator issues the integration credentials in the console; the detailed endpoint reference and the sandbox are in the console, open to the people your company authorises. To report a vulnerability: /.well-known/security.txt.The master data contract
UTF-8 CSV, semicolon separated, header row required. Required columns: tesisat_no, abone_no, abonelik_durumu, il, ilce. Optional: meter serial, address line, coordinates, subscriber type, contact details.
The file wins. A usage point absent from the file is not deleted but marked "not in source"; if a full file loses more than a fifth of its rows the run stops and asks the administrator.
Personal data
The platform holds no national identity numbers, invoices, debt or tariffs. Contact details are held only if the company provides them, and only as far as provided; once a subscription closes they are anonymised after the period set by the company.
Your company is the data controller and the platform operator is the processor; a data processing annex and a field list are attached to the contract.
From the first full load to the first period close.
Five steps; for most companies the first three take a few days, and the period test takes one billing period.
- 01 A boundary meeting: which data stays where, the usage point number format, the period calendar.
- 02 The first full load of the master data file and its validation report (same day).
- 03 A pilot meter group: installation work orders, first readings, read quality monitoring.
- 04 Testing the period index file in your billing system.
- 05 Optional: the integration client, API and webhooks, with developer testing in the sandbox.
The full endpoint list, schemas and sample code will be published in the developer portal. For early access, write to us.