API Overview

DocAI Fabric exposes a comprehensive REST API for programmatic access to all platform features.

Base URL

The base URL depends on your deployment:

• SaaS: https://app.docaifabric.com
• Self-hosted: Your configured domain (e.g., https://docai.yourcompany.com)

Interactive API Explorer

The built-in Swagger UI is available at:

https://app.docaifabric.com/api-docs

This provides interactive documentation where you can try API calls directly from your browser.

API Structure

The API is organized around these resource types:

Resource	Endpoint Prefix	Description
Tenants	/tenants/	Organization management
Projects	/tenants/{tenant_id}/projects/	Project CRUD and configuration
Workflow	/api/v1/tenants/{tenant_id}/projects/{project_id}/workflow	The project's draft workflow: its steps and their settings
Transactions	/tenants/{tenant_id}/projects/{project_id}/transactions/	Document upload and processing
Transaction Operations	/transactions/{transaction_id}/	Status, results, file upload, start processing
Admin	/admin/	Client and API key management
Health	/health	Service health check

Request Format

• Content-Type: application/json for most endpoints
• File uploads: multipart/form-data (for /transactions/{id}/source-files)
• All request/response field names use snake_case

Response Format

API responses return the resource directly:

{
  "transaction_id": "550e8400-e29b-41d4-a716-446655440000",
  "status": "completed",
  "created_at": "2025-01-15T10:45:00Z"
}

Error responses:

{
  "detail": "Error description"
}

Common Operations

Create a Project

curl -X POST "https://app.docaifabric.com/tenants/{tenant_id}/projects" \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Invoice Processing",
    "description": "Process vendor invoices"
  }'

Upload and Process Documents

# One-step: submit documents and start processing immediately
curl -X POST "https://app.docaifabric.com/tenants/{tenant_id}/projects/{project_id}/transactions/process" \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "source_files": [
      {
        "filename": "invoice.pdf",
        "base64_data": "JVBERi0xLjQK..."
      }
    ]
  }'

See Process Documents via API for the complete guide including multi-step workflows and dataset selection.

Read and Change the Workflow

The draft workflow is read and replaced as a whole. An agent connected over MCP does this with its workflow tools; the REST endpoints are there for scripts, and as a fallback.

# Read the draft workflow; the response's ETag header (and its "etag" field) names this version
curl -i "https://app.docaifabric.com/api/v1/tenants/{tenant_id}/projects/{project_id}/workflow" \
  -H "X-API-Key: your-api-key"

# Replace it, only if nobody changed it since you read it
curl -X PUT "https://app.docaifabric.com/api/v1/tenants/{tenant_id}/projects/{project_id}/workflow" \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -H 'If-Match: "<etag from the read>"' \
  -d @workflow.json

Reading needs access to the project. Changing the workflow needs the Configure project permission (project.configure), the same as editing it in the Workflow page. With If-Match, a workflow changed since your read is refused with 412 (workflow_changed): read it again and reapply your change. Without If-Match, the save replaces whatever is stored. Changes go to the draft and reach production when the project is published.

To change one step without sending the whole workflow, patch that step's settings. Name the keys to change; a key set to null is removed, and every key you leave out stays as it is. The rest of the workflow is not touched.

curl -X PATCH "https://app.docaifabric.com/api/v1/tenants/{tenant_id}/projects/{project_id}/workflow/nodes/{node_id}/config" \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"config": {"send_image": false, "max_text_pages": 20}}'

To turn a step off or back on, send "enabled": false or true beside (or instead of) config. If, Switch and Import steps cannot be turned off. Every workflow response lists the steps that are off in steps_turned_off, as each run decides it, so a client never needs to work that out itself.

If-Match works as for the whole workflow. Without it, the change is applied to the latest version, so two steps changed at the same time both keep their change. A change that would make the workflow invalid is refused with 422 (node_config_invalid) and lists what is wrong; an unknown step id gets 404 (workflow_node_not_found).

The da CLI covers the same endpoints. A step is named by its id, or by its name when no other step has it.

Command	Endpoint
da workflow get T P -o workflow.json	GET .../workflow, written with its etag
da workflow put T P workflow.json	PUT .../workflow, with the file's etag as If-Match (--force: without)
da workflow steps T P	GET .../workflow: the steps in run order and which are off
da workflow step get T P extract_1	GET .../workflow: one step's settings
da workflow step set T P extract_1 send_image=false --unset max_text_pages	PATCH .../nodes/{node_id}/config
da workflow step on / off T P split_1	PATCH .../nodes/{node_id}/config with enabled

A refused change exits with code 1 and prints the server's reason. da settings reads and writes the project's part, described next.

Where settings live

Each Split, Classify, Extract and Redact step holds its own settings in the workflow: its model, what it sends (images, text, page limits), whether it is on, for Classify and Extract its confidence threshold and whether it discovers new classes or fields, and, for Extract, whether Memory examples go into its prompt (use_memory). Change them on the step, as above. All of Split is the step's, its classes and guidelines included.

The project holds what every step shares: the document classes and their descriptions, the fields, the classification and extraction guidelines, extraction policies and Memory. Change those with PATCH .../settings. A step can carry its own text for a class, a field or the guidelines (guidelines_override, class_guidelines_override, field_guidelines_override), which it sends instead of the project's. A step can also work on part of the schema: classes on a Classify step and fields on an Extract step list the ids it uses (no list: all of them).

/settings refuses a step's settings with 400 (step_settings_on_workflow), naming them, and GET .../settings does not return them. A project stored in the older form, where the project held these settings, is converted the first time a request reaches it; one that cannot be converted is refused with 409 (project_not_converted) and can only be deleted.

Get Extraction Results

curl "https://app.docaifabric.com/transactions/{transaction_id}/documents" \
  -H "X-API-Key: your-api-key"

Next Steps

• Authentication: Set up API keys
• Process Documents via API: Submit, process, and retrieve document results via API
• Webhooks: Get results pushed to your endpoint instead of polling
• Datasets: Route transactions to Playground, Production, or Evaluation datasets
• Rate Limiting: Per-key limits, response headers, and retry behavior
• Open the Swagger UI at https://app.docaifabric.com/api-docs to try the interactive API explorer