Appearance
Operator API fixtures
Fixtures are the documented examples as real files. Each one is a request that DataFlair Stats sends and an answer that passes. The contract page shows the same file, so this folder, the page and the conformance check cannot disagree.
What is in the folder
| Folder | What it holds |
|---|---|
exemplary/ | The happy path. |
supplemental/ | Errors and edge cases. |
Each case is a folder with three files:
| File | What it holds |
|---|---|
request.json | The from and to that DataFlair sends as query parameters. |
expected-response.json | An answer that passes. |
case.json | How the check uses the case: the status it expects, the rules it applies, the docs section that explains it, and any value that was made up. |
The cases
| Case | Call | What it checks | Status |
|---|---|---|---|
exemplary/affiliate-daily | GET /api/reports/affiliate-daily | Returns daily rows per affiliate | 200 |
supplemental/single-day | GET /api/reports/affiliate-daily | A range of one day returns rows for that day only | 200 |
supplemental/invalid-date | GET /api/reports/affiliate-daily | A date that cannot be read is a 400 or 422 | 400 or 422 |
supplemental/missing-credentials | GET /api/reports/affiliate-daily | A request with no credential is a 401 or 403 | 401 or 403 |
supplemental/wrong-credentials | GET /api/reports/affiliate-daily | A wrong credential is a 401 or 403 | 401 or 403 |
The path is the convention. The check calls the URL you give it, as DataFlair calls the URL you save on the Integrations page.
Values that were made up
Every value comes from an example already in these docs. Where a value had to be invented, the madeUp list in that case's case.json says so. These are all of them:
supplemental/invalid-date
- from is "not-a-date", chosen only to be unreadable
- the contract says 400 and other 4xx. The checker accepts 400 and 422, the two usual answers
- the expected message is an example. Only the status is checked
supplemental/missing-credentials
- the expected message is an example. Only the status is checked
supplemental/single-day
- from and to are both the example day 2026-02-01. Test connection asks for a one-day range, and both ends of a range are inclusive
supplemental/wrong-credentials
- the wrong credential is generated by the checker
- the expected message is an example. Only the status is checked
An error case checks the status only. The contract does not give an error body shape.
Use them
- Replay them with the conformance check.
- Or replay one by hand. Send the
fromandtoinrequest.jsonto your endpoint withcurl, with your credential in the header. Compare the answer withexpected-response.json. Your affiliates and numbers will differ. The fields must match.