Let's stand up a working order API. Defining one entity generates a full set of endpoints your app can call immediately.
1 · Define the entity
In API Studio, create the entity. Under the hood this POSTs a single definition to the apistudio gateway. The key parts are the field catalog (UpdateParams) and the record key templates (baseKeys).
POST /api/create-order
{
"entityName": "order",
"baseKeys": {
"pkTemplate": "org#{org};data#order",
"skTemplate": "order#{id}"
},
"UpdateParams": [
{ "name": "id", "colType": "guid" },
{ "name": "title", "colType": "string", "validate": true, "minlength": 1 },
{ "name": "amount", "colType": "number" },
{ "name": "status", "colType": "enum", "enumValues": ["pending", "shipped"] }
]
} What this writes
The handler stores the primary create-order definition and generates four more configs — get, list, update, delete. No order table is created; records land in the shared app table under org#…;data#order.
2 · Call the generated routes
Your app's users now have a complete entity API on the app gateway. Every route is authenticated with the app token and scoped to the caller's workspace.
POST /app/{orgCode}/create/order create a record
GET /app/{orgCode}/item/order/{id} read one
PUT /app/{orgCode}/update/order/{id} update fields
DELETE /app/{orgCode}/delete/order/{id} delete
GET /app/{orgCode}/list/order list (filters, search, paging)
GET /app/{orgCode}/count/order { count } 3 · Create a record
curl -X POST https://{domain}.nostackai.com/app/{orgCode}/create/order \
-H 'Authorization: <app-token>' \
-H 'Content-Type: application/json' \
-d '{ "title": "First order", "amount": 49, "status": "pending" }'
# -> 200 { "id": "a1b2c3..." } Why only the id comes back
Create and update responses return only the fields named in the entity's default response view — by default just id. This avoids echoing the whole record on write. You shape richer responses with views.