> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.itential.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server.

# Schemas overview

> An introduction to adapter schema files and how they define and translate data betweenItential Platform and an external system.

Schema files define the data an adapter sends to and receives from the external system it integrates with. Schema does not define the overall format of that data — that is controlled by `requestDatatype` and `responseDatatype` in `action.json`. Schema is only applied when the datatype supports translation, such as `JSON`, `XML2JSON`, or `URLENCODE`.

Schema files live within the adapter's endpoint configuration at `adapter-home-dir/entities/<entity-name>/`. You can use multiple schema files in a single adapter. Every action can have:

* A **request schema** that defines the data sent to the external system.
* A **response schema** that defines the data received from the external system.

The request and response schemas do not have to be separate. For CRUD operations they are often the same file.

## Why schemas matter

Different systems name the same data differently. Schema files let the adapter translate field names automatically so that each system receives data in the format it expects.

For example:

* System A calls a device IP address `ip_addr`.
* System B calls it `ipaddress`.
* Itential Platform calls it `ip_address`.

WhenItential Platform retrieves a device from System A, the adapter schema maps `ip_addr` → `ip_address` automatically. WhenItential Platform adds a device to System B, the schema maps `ip_address` → `ipaddress`. This translation happens in the adapter libraries based on the field mappings you define in the schema.