A logic block is a multi-step execution pipeline — the alternative to plain entity CRUD. You define an ordered list of steps; the execution engine runs them in sequence at request time, passing data between them. Like everything else, a logic block is configuration, not deployed code.
When to use one
- You need to read or write several entities in one call.
- You need branching (
condition) or iteration (loop). - You need to call an external system (
webhook,connector) or AI (ai_call,run_crew). - You want a single, named endpoint that encapsulates a workflow.
Define vs run
You build logic block definitions in API Studio (CRUD on config records). Your app runs them on the app gateway.
POST /app/{orgCode}/logicblocks/{apiname}
POST /app/{orgCode}/logicblocks/{apiname}/{pathid+} The optional greedy {pathid+} suffix lets a logic block take one or more path segments. Declare each one in inputSchema.pathParams (e.g. { name: "id", required: true }) — segments map positionally from the greedy capture to input._path.<name>, and a required param missing at request time returns 400.
Streaming for long-running AI
For token-streaming or long agentic runs, invoke the logic block over the WebSocket customapi_run action instead of the HTTP route — ai_call steps stream tokens live as the run executes, so the client can render output as it's produced.
AI Design — generate a draft
You can describe a workflow in natural language and have AI Design generate the step definitions as a starting point. Treat the output as a first draft to review and refine — it's a build-time tool, not a runtime feature.