One source.
One useful record.
Begin with a small, explicit contract. Inspect the example below, download the files, and adapt the field meanings to your own authorized workflow.
STATIC EXAMPLES · NO CREDENTIALS REQUIREDMake absence
part of the design.
This example describes a fictional catalog item. The price is represented as decimal text, the source is identified, and unavailable availability remains null. The issue list explains the absence.
The timestamp belongs to the illustration. It is not an observation from a live source. These downloadable files do not submit requests, authenticate a user, or connect to an extraction service.
Get the example files ↓{
"schema_revision": "1.0",
"source_id": "catalog-demo-01",
"observed_at": "2026-09-13T00:00:00Z",
"record": {
"name": "Example reusable bottle",
"price_amount": "24.00",
"currency": "USD",
"availability": null
},
"issues": [
"availability_not_present"
]
}Read the contract, not just the keys
The envelope identifies the source and observation context. The record contains selected business fields. The issue list preserves an explicit reason for a missing value. Use a different representation when your consumer needs one, but document the decision rather than leaving it to interpretation.
| Example field | Meaning in this contract |
|---|---|
| schema_revision | A visible version for the record contract. |
| source_id | A stable identity for the approved source. |
| observed_at | When the source was observed, distinct from publication time. |
| record.name | The item this record describes. |
| record.price_amount | Decimal text chosen for this example; not a numeric identifier. |
| record.currency | Currency context for the price. |
| record.availability | Null because the example supplies no supported availability value. |
| issues | A machine-readable explanation of missing or rejected fields. |
Four checks before delivery
Parse: confirm the output is a valid serialization. Validate structure: check types, required fields, and unexpected properties. Check meaning: apply the rules required by the task. Check evidence: confirm that important values are supported by the intended source item.
The supplied schema is a structural example. It does not prove that a source exists or that the values are true. Date-time format checking also depends on the validator and its configuration. Keep these checks separate in your implementation and include expected failures in the review set.
Consult the source documentation for implementation details and current access conditions. The workflow above is an editorial planning pattern.
Download the examples
Connect the pattern to an implementation
Choose the source and access route, then implement retrieval and extraction in an environment appropriate to the workload. Keep credentials out of static pages and client bundles. Add output validation before connecting records to a downstream action.
Start with the data contract article, continue to the JSON validation guide, and use the deployment overview when selecting a runtime. None of the examples require or imply an ExtractAPI.com API key.