Sample payloads
Download the sample payloads below, or all of them as a zip. Each statement sample is real output from a real bill, with account numbers, names and addresses replaced by placeholders. Start with the first.
| Sample | Event or call | What it shows |
|---|---|---|
01-input-connection-create.json |
POST /v1/connections |
Registering a login |
01b-output-connection.json |
POST /v1/connections answer |
A new connection, before its first run |
02-output-run-requested.json |
POST /v1/connections/{connection_id}/runs answer |
A run you triggered, queued |
03-input-upload-request.json |
POST /v1/statements |
Uploading a bill by reference |
04-output-accounts-discovered.json |
GET /v1/connections/{connection_id}/accounts |
Three accounts after two runs: one active, one never collected, one active and no longer listed |
05-output-statement.json |
statement.available |
A multi-service municipal bill with two separate water blocks, and charges attributed from their own printed words |
06-output-statement-flagged-for-review.json |
statement.available |
A statement that balances and is still review, because current_charges was derived rather than read |
07-output-statement-summary-parent.json |
statement.available |
A summary parent with charges of its own, and its children block |
07b-output-statement-summary-child.json |
statement.available |
One child of that parent |
09-output-statement-bundle-member.json |
statement.available |
One of seven unrelated bills uploaded in a single scanned PDF |
10-output-statement-summary-parent-adjusted.json |
statement.available |
A 49-child parent that balances with its adjustments |
11-output-statement-summary-parent-per-meter.json |
statement.available |
Twelve children, seven sharing one account and address, told apart by meter_numbers |
08-output-request-failed.json |
request.failed |
A request that produced no statements |
12-output-statement-withdrawn.json |
statement.withdrawn |
A statement a re-extraction no longer contains |
13-output-request-duplicate.json |
request.duplicate |
A file sent a second time |
14-output-retrieval-completed.json |
retrieval.completed |
A run that listed two accounts, one of them new, and noticed one missing |
15-output-retrieval-failed.json |
retrieval.failed |
A scheduled run the portal refused the password for |
Samples 01 to 04 are the connection API's request and response bodies, not webhook payloads. On statements, connection_id and account_id appear only for retrieved bills, and provider is not yet sent (see The statement payload). Fields whose names begin with _ are explanatory notes for readers and never appear in real payloads.
JSON Schemas
We publish a JSON Schema (draft 2020-12) for each body we send, named after its Luminetric-Event: statement.available.schema.json, request.failed.schema.json, statement.withdrawn.schema.json, request.duplicate.schema.json, retrieval.completed.schema.json and retrieval.failed.schema.json. Use them to generate types or to validate what reaches your webhook.
They are open by design, so that validating against them never breaks when we add to a major version:
- Fields the schema does not name are allowed. Ignore the ones you do not use.
- Enumerated fields list the values we send today under
x-known-values, not as a closedenum. A value not in that list is valid; handle it as Compatibility and versioning describes. schema_versionmust match the schema's major version. A body from another major version fails validation, which is the signal to move to that version's schemas.
Each delivery is checked against these schemas before we send it.