Co-Wright — builders

API Builder

Every entity in your model carries a generated REST API — documented, permissioned, and queryable — before anyone writes a line of integration code. And when standard operations aren't enough, custom routes are built on your own SQL.

Schedule demo

From model to API

Deploy a model and every entity comes back as a set of working operations — count, create, read, update, and remove — each with a generated path, generated parameter documentation, and worked request examples down to the curl command. The reference isn't a document someone maintains; it's produced with the API itself.

Remove respects the model: entities configured with soft deletion keep removed records recoverable, and the API leaves deleted rows out of results unless you ask for them.

Declared on the model →

Contact

first_name

last_name

is_active

entity_id

GETCount all entries/contact/count/all

POSTCreate new/contact

GETGet all entities/contact

GETGet by ID or UUID/contact/{id|uuid}

DELETERemove specific/contact/{id}

PUTUpdate existed/contact/{id}

QueryfilterattributesincludesgroupByorderlimit/offset

The Contact entity's generated operations — every entity in the deployed model gets the same set, and every GET accepts the query surface below.

Queryable, not just callable

Generated endpoints accept real query semantics, not just lookups: choose the attributes that come back — including across reference chains — filter with typed operators, include related records, group with aggregations, order across included associations, and page with limit and offset. Work that usually means a custom endpoint per question is a request body here.

Explore the API

The deployed reference for the same CRM model you've seen built — every operation live, every parameter documented.

A working wireframe of the deployed API reference, seeded with illustrative CRM data — a rough picture of the experience, not the production product.

When standard isn't enough

Custom routes are built on extensions — your own SQL views, procedures, and functions, living alongside the model. A route binds to an extension, declares its methods, and deploys with the rest of the API. The same extensions can be queried directly from the portal, so the logic you write once serves your integrations and your people.

The warehouse underneath →

Build a route

Name it, bind it to an extension, declare its methods.

A working wireframe of the route builder, seeded with illustrative CRM data — a rough picture of the experience, not the production product.

Nothing hidden

Generated documentation

Every parameter documented with worked examples and curl samples, produced with the API itself.

The SQL, visible

The commands a deploy runs are inspectable in the portal — no black box between your model and your database.

Every generated file

Client views and server routes are listed per deploy; you can see exactly what was produced.

Permissioned by role

Calls are authenticated, and what a role can read or write in the portal holds at the API.

Security & permissioning →

The model, the screens, the API

One definition produces all three. That's the platform the portal runs on.

Schedule demo