Skip to main content
On this page

CQRS

Before you read any API reference, internalize this: the entire etg24 integration surface is split into two kinds of operations.

Commands change state, queries read data

  • Queries read data. They never change anything. Safe to retry, safe to run with read-only keys.
  • Commands change state — create, update, delete. They are explicit, targeted actions with an audit trail.

In the REST API this split is visible in the URL:

GET  /propertymanagement/v2/query/contacts        read a list
POST /propertymanagement/v2/command/contacts.create  create a contact

In MCP the same split exists: every tool is either a query tool or a command tool, and the tool reference marks each one. A query tool you call fearlessly; a command tool you call deliberately.

Why this matters for you

CQRS is not an implementation detail — it is the mental model for everything you build on the platform:

  • Read-only permission scopes map directly onto queries. A key scoped to read access can run every query and no command. See Permission scopes.
  • Commands are the boundary of auditability. Every command is recorded and attributable to the exact agent that ran it. See Change attribution — and Rollback for the recovery workflow.
  • Rollback is possible because soft delete means most destructive commands are reversible.

One rule of thumb

When you design an integration or an agent, ask for every operation: does it change the world? If not, it’s a query — read-only, retry-safe, low-risk. If yes, it’s a command — scoped, audited, and worth testing carefully.