Source changes

Websites evolve. A collection can change its layout, URLs, fields, available records, or access requirements. Review the returned records and execution summary before sending changed output downstream.

A partial run is still partial#

Imagine the fictional table-lamp API returned some products after its source changed, but could not complete all work within the requested scope. An illustrative result could contain:

{
  "records": [{ "name": "Arc table lamp", "price": 48, "currency": "USD" }],
  "summary": {
    "status": "partial",
    "within_scope_passed": false,
    "catalog_complete": false
  }
}

This is a teaching example, not a captured response or a promise that every run uses this exact shape. Nonempty records and HTTP 200 do not override summary.status or summary.within_scope_passed. catalog_complete: false also rules out a full-catalog claim.

Preserve evidence and decide#

Keep the records with their summary, requested limits, source identifier, definition version, and non-secret run or trace identifier. Compare the returned fields and examples with the accepted schema. If your workflow requires complete coverage or a required field is missing, hold the result from downstream use while you investigate.

Check whether the source definition or schema changed. Review a new definition before updating the version pinned by your application. Some changes require a different collection approach or make the source unavailable; a successful retry alone does not prove recovery.

Continue safely#

Read pagination and output to distinguish a deliberately bounded run from an incomplete one, and errors and retries before repeating an uncertain execution. Source status covers monitored sources; it does not establish the health of every generated API.