A record shape you can actually inspect.

Scope of this reference

This reference documents the fixed customer example on ImportAPI.com. It describes local JavaScript behavior and downloadable JSON fixtures. There is no HTTP endpoint to call, no authentication header, and no live record-storage operation. Use these shapes as a starting point for designing your own application contract.

Source records

The source is an array containing three objects. Each object has the string fields Customer ID, Name, and Country. The example intentionally includes one missing identifier and one name with surrounding spaces. The source data is fixed in the page script, so the demonstration accepts no user-entered or uploaded records.

Mapped records

The mapping creates external_id, name, and country. It trims surrounding whitespace, uppercases the country string, and adds source_record, a one-based position in the original array. Identifiers stay strings. This mapping does not merge records, infer missing values, or consult a destination.

Validation rules

Both external_id and name must be nonempty after trimming. The local exercise accepts the country labels GB, US, and FR. Each failure contains a field, a stable code, and a readable message. A record with at least one failure is rejected; otherwise it is accepted.

Outcome envelope

evaluated counts source records. accepted contains the mapped records that passed these checks. rejected contains the source record number and errors for each unsuccessful record. For this fixture, accepted plus rejected equals three. Accepted here means validated by the example, not committed to an application.

{
  "evaluated": 3,
  "accepted": [
    {
      "source_record": 1,
      "external_id": "001",
      "name": "Ada",
      "country": "GB"
    },
    {
      "source_record": 2,
      "external_id": "002",
      "name": "Milo",
      "country": "US"
    }
  ],
  "rejected": [
    {
      "source_record": 3,
      "errors": [
        {
          "field": "external_id",
          "code": "required",
          "message": "Supply a stable customer identifier."
        }
      ]
    }
  ]
}

Extending the contract

A production workflow needs additional decisions: authorization, identity conflicts, schema evolution, source retention, and commit behavior. Keep these decisions separate from the example’s narrow validation rules. A schema can describe expected structure without proving that a record belongs to a particular customer or tenant.

Read the reliable batch import guide before designing retries. Use the schema mapping guide to make transformations and business checks independently testable.