API Action Types

API action types are pre-built reusable “verbs” you can attach to any datastore — approve, archive, duplicate, transfer, recalculate. They save you from writing the same custom function many times when the pattern is identical across record types.

Available Action Types

• Approve / Reject: Idempotent state transitions with audit.
• Archive / Unarchive: Hide from default views without true deletion.
• Duplicate: Copy a record (and optionally its children) with a new ID.
• Transfer ownership: Change the user or tenant that owns a record.
• Lock / Unlock: Prevent further edits.
• Tag / Untag: Apply labels in bulk.
• Trigger workflow: Kick off a configured workflow.

How They're Exposed

Once enabled for a datastore, each action becomes available as:

• API endpoint: POST /api/records/{table}/{id}/approve etc.
• Bulk endpoint: POST /api/records/{table}/bulk/approve with an array of IDs.
• UI button: Appears on the record's edit page (if enabled in the layout).
• Workflow step: Other workflows can invoke action types.

Worked Examples

• Order approval: Enable Approve/Reject on Orders. Backend systems call POST /approve when their checks pass.
• Document archival: Bulk archive 6-month-old documents nightly via a scheduled task.
• Duplicate a quote: User clicks “Duplicate” on a quote; the action copies the quote and line items with a new quote number.
• Bulk tag: Mark all customers in a region with a “2025-priority” tag in one bulk call.

Most API action types interact with standard fields — status, approved_by, approved_at, archived. Default field mappings tell the platform which column on each datastore maps to which semantic concept, so generic actions work without per-datastore code.

Standard Semantic Fields

• status — workflow state (e.g. draft, submitted, approved, rejected).
• archived — boolean; if true the record is hidden from default views.
• locked — boolean; if true edits are blocked.
• approved_by, approved_at — audit trail for the approval action.
• archived_by, archived_at — audit trail for archival.
• owner_user_id, owner_tenant_id — for ownership transfer.

Why Override the Defaults

If your datastore predates the platform conventions, its columns may have different names. Override the mapping so actions work against your existing schema. For example, an old datastore may have state instead of status, or deleted instead of archived.

How to Override

1. Open Architect Panel → Datastores → (table) → Field Mappings.
2. For each semantic field, pick the actual column from a dropdown.
3. Save.

Worked Examples

• Legacy orders table: The state column maps to status; the deleted column maps to archived. Generic Approve / Archive actions now work.
• Custom field names: An app uses doc_owner instead of owner_user_id — map accordingly; Transfer Ownership works against it.
• Multi-tenant override: One tenant has historical schema with different column names; override per-tenant in Per-Tenant Configuration.