Fields and schemas

Decide what one useful record should contain before connecting an API to your application. Field names, types, and missing values all matter.

Review one record shape#

Continue the fictional table-lamp collection. A reviewed example might contain:

{
  "name": "Arc table lamp",
  "price": 48,
  "currency": "USD",
  "availability": "in_stock",
  "url": "https://example.com/lighting/table-lamps/arc"
}

These are illustrative values, not data fetched from a website or a universal CleanedWeb schema. Check each proposed field against observed records: is price a number, is its currency known, and does url identify the individual product? A displayed price without a confirmed currency should not silently become USD.

Account for missing values#

Another lamp may omit availability. Preserve that absence according to the generated schema; do not invent in_stock or turn a missing price into zero. Decide whether your application can accept an incomplete record and which fields it requires.

Review several examples when available. A field observed on one record does not establish that every record has it. Detail fields may also depend on whether detail enrichment is included in the validated collection plan.

Accept the generated contract#

An inspection preview shows possible data. A selected type or a build in progress is not an accepted API. After a successful build, review its saved schema, example records, source identifier, definition version, and collection limits in your workspace. Compare them with the fields your application needs; proceed only when the validated output fits that use.

The fictional product fields above do not prescribe endpoint names or inputs. Use the exact request example and contract supplied by the accepted build. The quickstart shows a bounded first request and explains why to pin the definition version. Then read pagination and output before increasing collection limits.