Fixtures

Fixtures are the documented examples as real files. Each one is a request that DataFlair sends and an answer that passes. The endpoint pages show these same files, so this folder, the pages and the conformance check cannot disagree.

Download all fixtures (.zip)

What is in the folder

Folder	What it holds
exemplary/	The happy path. One case for each endpoint.
supplemental/	Errors and edge cases.

Each case is a folder with three files:

File	What it holds
request.json	What DataFlair sends.
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/health	GET /health	Returns the account and its capabilities	200
exemplary/inventory	GET /inventory	Lists the bookable slots	200
exemplary/forecast	POST /forecast	Returns available and forecasted impressions	200
exemplary/orders	POST /orders	Creates a draft order	201
exemplary/reports	POST /reports	Returns impressions and clicks per line	200
supplemental/health-bad-key	GET /health	A wrong key is a 401 with an error body	401
supplemental/forecast-unknown-slot	POST /forecast	An unknown inventory_id is a 404 with an error body	404
supplemental/orders-draft-only	POST /orders	A booking with no creative still returns draft line items that do not serve	201 or 200
supplemental/orders-replay	POST /orders	A repeat of the same idempotency_key and body returns the same ids	200
supplemental/orders-conflict	POST /orders	The same idempotency_key with a different body is a 409	409
supplemental/orders-update	POST /orders	A new idempotency_key with the same external_ref updates the existing order	200
supplemental/orders-unknown-slot	POST /orders	An unknown inventory_id is a 404 with an error body	404
supplemental/reports-daily	POST /reports	granularity daily returns a date on every row	200

The draft-only rule as a test

The draft-only rule is a test here, not only a paragraph. The case supplemental/orders-draft-only sends a booking with no creative. The check then asserts that the order and every line item come back as DRAFT. An order that comes back as ACTIVE fails the case.

Values that were made up

Every value comes from an example already in these docs or in the OpenAPI file. Where a value had to be invented, the madeUp list in that case's case.json says so. These are all of them:

supplemental/health-bad-key

• the wrong key value is generated by the checker
• the expected error code unauthorized and message are examples. The contract does not fix them

supplemental/orders-conflict

• line_items[0].goal_impressions is 200000, chosen only so the body differs from the exemplary case
• the expected error code idempotency_conflict and message are examples. The contract does not fix them

supplemental/orders-draft-only

• the DRAFT key, order name, external_refs and the ids in the expected response are derived by suffixing the example values

supplemental/orders-unknown-slot

• the idempotency key, order name and external_refs are derived by suffixing the example values

The check tests the shape of an error, not its wording. It does not compare your code or message with the examples.

Use them

• Replay them with the conformance check. It swaps in a slot from your own GET /inventory, so the example slot ids do not have to exist on your server.
• Or replay one by hand. Send request.json to your server with curl, and compare the answer with expected-response.json. Your ids and numbers will differ. The fields and the states must match.