Define the API Data Model

Step 2 · Data model

Turn the API objects you need into NIM tables before writing requests.

What you are buildingDirect link to What you are building

Each item in schema.crud_objects becomes a NIM data table. Start with the objects needed for your goal—usually users, groups, and memberships—not every endpoint an API offers.

"schema": {
  "crud_objects": {
    "users": {
      "key": "id",
      "resources": { "id": "string*", "displayName": "string*", "email": "string" },
      "operations": { "get_users": { "method": "get", "call": { "mode": "normal", "path": "/users" } } }
    }
  }
}

Build each table in four partsDirect link to Build each table in four parts

Resources — the API fields NIM stores as columns.
Key — the stable resource that uniquely identifies a row.
Group membership — optional, for a membership table that connects users and groups for role models.
Operations — the read and write calls available for that table.

Start with read

Define resources, a key, and one GET operation first. Collect and inspect real API data before enabling create, update, or delete.

Naming rules that keep connectors maintainableDirect link to Naming rules that keep connectors maintainable

Use the API entity name for the table where possible: users, groups, employees.
Keep resource names stable once mappings use them.
Mark a resource with * when NIM should select it for collection by default.
Use the _:type resource prefix only when nested API fields would otherwise create the same NIM column name.