Developer documentation

Apeirum API

Integrate Workspace AI capabilities into your company systems with authentication, structured responses, traceability, and approved-access flows.

Overview

The Apeirum API is the technical path for connecting parts of Workspace AI to digital products, internal systems, and business routines. Access is approved by scope, and final integration contracts are defined with the Apeirum team.

Workspace AI

Connect Chat, Library, Dashboard, API, and integrations with company systems.

Structured responses

Return answer, structured_data, evidence, status, job_id, and metadata when applicable.

Approved scope

Credentials, limits, schemas, and support are defined before production.

Access and contracting

The API is not an unrestricted public endpoint. Usage depends on approval, commercial agreement, and technical alignment.

Approved access before production usage
Contracting by plan, scope, and/or request usage when applicable
Use for companies, digital products, and internal systems
Schemas, limits, and SLAs defined by proposal

Authentication

The integration pattern uses an API key in a header. In production, treat the key as a server-side secret and never expose it in a client.

Send x-api-key in every approved request
Use Content-Type: application/json for JSON payloads
Store the key in an environment variable or secret vault
Plan key rotation and revocation when needed

Quickstart

The examples below show the expected integration format. Base URL, endpoints, and final schemas may vary according to the approved contract.

cURL
example
curl -X POST "$APEIRUM_BASE_URL/v1/answers" \
  -H "x-api-key: $APEIRUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "Quais itens exigem revisão?",
    "scope": "workspace_contract",
    "include_evidence": true
  }'
JavaScript / TypeScript
example
const response = await fetch(
  `${process.env.APEIRUM_BASE_URL}/v1/answers`,
  {
    method: "POST",
    headers: {
      "x-api-key": process.env.APEIRUM_API_KEY,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      question: "Quais itens exigem revisão?",
      scope: "workspace_contract",
      include_evidence: true
    })
  }
);

const data = await response.json();
PowerShell
example
$headers = @{
  "x-api-key" = $env:APEIRUM_API_KEY
  "Content-Type" = "application/json"
}

$body = @{
  question = "Quais itens exigem revisão?"
  scope = "workspace_contract"
  include_evidence = $true
} | ConvertTo-Json

Invoke-RestMethod `
  -Method POST `
  -Uri "$env:APEIRUM_BASE_URL/v1/answers" `
  -Headers $headers `
  -Body $body

Basic integration flow

A typical integration sends a document or data, queries authorized context, receives a structured response, and tracks status when processing is asynchronous.

1. Send input

Document, data, event, or question arrives with a defined purpose.

2. Create or query context

The integration informs scope, user, routine, or authorized collection.

3. Get response

The API returns answer, structured_data, evidence, status, and metadata when applicable.

4. Check job

Asynchronous flows expose job_id and status for tracking.

5. Receive callback

When contracted, webhooks return relevant events to the destination system.

Endpoints and integration contracts

The paths below are scoped integration contract examples. They document the expected design without promising unrestricted public availability.

Model

Base URL, version, and final payload are defined in the approved scope.

POST /v1/documents

Send a document or file for approved processing.

GET /v1/jobs/{job_id}

Check status, error, or completion of asynchronous processing.

POST /v1/answers

Send a question or data and receive a structured response.

POST /v1/webhooks

Register a callback when the contracted flow requires asynchronous return.

Response example

Responses may combine text, structured data, evidence, and metadata. Final fields depend on the contracted schema.

response.json
example
{
  "job_id": "job_01hx_example",
  "status": "completed",
  "answer": "Há três itens que exigem revisão antes de seguir.",
  "structured_data": {
    "items": [
      {
        "label": "Prazo de renovação",
        "risk": "medium",
        "requires_review": true
      }
    ]
  },
  "evidence": [
    {
      "document_id": "doc_01hx_example",
      "excerpt": "Renovação automática por 12 meses salvo aviso prévio.",
      "location": "page 4"
    }
  ],
  "metadata": {
    "request_id": "req_01hx_example",
    "scope": "workspace_contract"
  }
}

Errors

The codes below guide failure handling in clients and integrations. Final messages may vary by contract.

400

bad_request

Fix payload, required fields, or format.

401

unauthorized

Check missing or invalid API key.

403

forbidden

Confirm whether the contracted scope permits the action.

404

not_found

Check identifier, job, or requested resource.

429

rate_limited

Respect rate limit and retry with backoff.

500

server_error

Log request_id and contact technical support if it persists.

Limits and usage

Limits are defined by scope, plan, or contract. Billing may consider plan, volume, authorized endpoints, support, and request usage.

Rate limits by key, organization, or flow
Quotas by plan, contract, or usage window
Usage metering when applicable
No final price table when scope still depends on proposal

Security and review

The integration should preserve operational control. Sensitive cases need logs, permissions, human review, and limits before external actions.

Logs and request_id for audit
Permissions by organization, key, and scope
Traceability and evidence when required by the flow
Human review before recording, sending, or triggering external actions
Automation limits defined by contract
API

Ready to map an integration?

Talk about destination system, volume, data, expected responses, callbacks, and review requirements. Apeirum defines the technical contract from the approved scope.