Start from the metadata contract
An entity's Design Studio detail page is the shared contract beneath every developer surface. Its overview links the model to Fields, Relations, Views, Record Types, Actions and Layouts; together those definitions determine API shapes and supported experiences, and the same metadata can be pulled by the CLI or described through MCP. Process Studio, Data Studio and Sense AI Studio add executable, analytical and AI-facing extensions without bypassing this model.
- 1
The entity header identifies the logical model whose contract you are inspecting.
- 2
Capability cards show which create, edit, delete, merge, tracking and view behaviors the entity supports.
- 3
Relationships & Usage links Fields, Record Types, Relations, Views, Actions and Layouts back to the same entity contract.
- 4
Schema, Logic and Experience organize the metadata you should verify before hard-coding an integration assumption.
Start development by opening the entity definition and checking permissions before writing code. Confirm logical names rather than display labels, use supported metadata instead of hard-coded assumptions, and test as the intended user because API and MCP calls inherit that identity's grants.
Most xMatix customization needs no code at all — the data model, layouts, business rules, workflows and approvals are all built in the product, and the customization guide covers them end to end. This section is for the work that sits beyond that: putting a tenant's configuration under source control, reading and writing records from your own systems, connecting AI tools to governed data, and extending the integration hub. Everything here rides on the same platform services and the same security model as the product itself — a developer surface never grants more than the signed-in user is permitted.
The developer surfaces
| Surface | What it does | Start here |
|---|---|---|
| The CLI | A git-friendly, round-trippable view of every customizable artifact in a tenant — scripts, business rules, workflows, dashboards, reports and metadata — so configuration can be versioned, reviewed and promoted like code | CLI overview |
| Data API | REST endpoints over every entity in the tenant — list, read, create, update, delete, invoke actions, expand relations, page and filter — with the caller's permissions always applied | The data API |
| MCP endpoint | The platform speaks the Model Context Protocol, so AI assistants and agent frameworks can list entities, query records and search knowledge under the calling user's permissions | The MCP endpoint |
| Integration connectors | The connector engine behind the integration hub — compiled connectors for special transports, manifest connectors for REST partners | Connector authoring |
| Script runtime | Server-side C# in a sandbox, attached to save-lifecycle phases and action buttons — authored in the product, and round-trippable through the CLI | Your first automation script |
How the pieces relate
The script runtime is documented with the rest of customization because scripts are authored and tested inside the product; what this section adds is the CLI's scripts commands, which let you edit the same scripts in your own editor, push versions from git, and tail execution history from a terminal. The data API is the same API the product's own web and mobile clients run on — there is no separate "integration API" with different behavior, so a record written through the API fires exactly the automation a record saved in the UI fires (what runs when you save a record). The MCP endpoint exposes a read-only tool set over those same services for AI clients, and the reverse direction — bringing your tools to the platform's AI — is configured in AI Studio and described in Extending Sense. Connectors belong to the integration hub, where scheduled flows move data between xMatix and external systems; the authoring page explains how new REST partners are added as reviewed manifest files rather than code.
The pages in this section
| Page | What it covers |
|---|---|
| CLI overview | What the CLI is, installing it, and the full command map |
| CLI quickstart | A first session end to end: sign in, export the tenant, push a change |
| Authentication | The device-code sign-in, the token cache, and workspace configuration |
| Metadata, Workflows, Scripts, Rules, Dashboards & reports | Round-tripping each artifact kind |
| Migrations, Snapshots, CI recipes, Workspace layout | Whole-repository operations and pipelines |
| The data API | The REST surface over entities, queries and actions |
| The MCP endpoint | AI tools over governed data, in both directions |
| Connector authoring | The two connector tiers and the manifest contract |
| Troubleshooting | Developer-surface symptoms and their fixes |
Common questions
Do I need any of this to customize xMatix?
No. Every customization tool — entities and fields, layouts, business rules, workflows, approvals, even automation scripts — has a full authoring experience inside the product, and administrators use them without touching a terminal. The developer surface earns its keep when you want configuration in git with pull-request review, changes promoted by pipeline instead of by hand, records flowing to and from your own systems, or AI tools reading tenant data under governance.
What authentication do the developer surfaces use?
OAuth 2.0 bearer tokens issued by your organization's sign-in authority — the same identity that signs users into the product. The CLI acquires tokens with a device-code flow and caches them encrypted per tenant; API and MCP calls present a bearer token and execute as that user, with security profiles and the rest of the security model applied on every request.
Can an API integration see more than a user can?
No — there is no bypass tier. Every request executes as the authenticated user, and the platform applies that user's permissions, record security and restriction rules on the server for every read and write. Designing an integration therefore starts with deciding which user it should act as, and granting that account exactly the access the integration needs.