API overview
What the APROS REST API covers, where to send requests, how responses are shaped, and how the API is versioned.
The APROS API lets your own systems read and change the data in your workspace: CRM records, projects and tasks, the product catalogue, quotes, invoices and orders, documents and files, and your organization's reference data. It is a REST API that speaks JSON over HTTPS, and it is described by an OpenAPI 3.1 document that the API reference on this site is generated from.
Quickstart
Make your first authenticated call, list leads and create one.
Authentication
Create an API key, choose its scopes, rotate and revoke it.
API reference
Every endpoint, parameter and permission, generated from the platform's own spec.
MCP server
Connect Claude or Cursor to your workspace with the same permissions model.
Base URL
Every APROS workspace has its own address, and its API lives on that address. Send requests to the host you sign in at:
https://<your-workspace>.apros.app/api/...For example, the leads collection is https://<your-workspace>.apros.app/api/leads. There is no
shared API host: an API key belongs to the workspace that issued it and works only there.
What the API covers
The API reference groups the API's 394 operations into 42 groups; expand a group in its sidebar to see its operations. The groups fall into these areas:
| Area | Groups in the reference |
|---|---|
| CRM | Lead, Contact, Company, Deal, Pipeline, Activity, Comment, Timeline, Saved filter |
| Projects and tasks | Project, Task |
| Catalogue and pricing | Product, Product category, Product attribute, Product attribute group, Product attribute value, Product attribute assignment, Product image, Product tag, Unit, Price list, Price list entry, Price list entry tier, Price |
| Sales and finance | Quote, Invoice, Order, Tax rate, Currency, Number sequence |
| Documents and files | Document, Document record, File |
| Organization | Organization, Legal entity, Department, Employee, Industry, Directory |
| Custom entities | Custom entity — your own record types and their records |
| Your credential | Me — GET /api/me/scopes describes the key you are calling with |
| Workflows | Inbound webhook — start a published workflow from another system (see Webhooks) |
The public API does not include the AI layer (AI Brain, agents, skills), building workflows and automations, mail, calls, conversations, the feed or the work day. It also does not create users, manage roles or issue API keys: you do those in the product.
Modules and permissions decide what you reach
Most endpoints require a permission, and most belong to a module of your workspace. A call that
needs a module your workspace has switched off answers 403 with the code MODULE_DISABLED. A call your
key is not scoped for answers 403, usually with the code ACCESS_DENIED. See
Authentication and Errors.
Requests
- Use HTTPS, and send request bodies as JSON with
Content-Type: application/json. - Authenticate every request with
Authorization: Bearer <api-key>. See Authentication. - Record IDs are UUIDs.
- Timestamps are ISO 8601 date-times, for example
2026-10-18T09:30:00.000Z. - Decimal amounts, such as a lead's
estimatedBudget, come back as strings so that no precision is lost. Send them as numbers where the request schema saysnumber. - Seventeen create endpoints accept an
Idempotency-Keyheader so you can retry them safely. See Retrying safely.
Responses
Read each operation's own response description in the reference. Neighbouring endpoints do not all use the same envelope, and the reference states the top-level keys of every response:
- Most list endpoints answer
{ "items": [...], "total": ... }, usually with paging fields. See Pagination, filtering and sorting. - Some detail endpoints wrap the record:
GET /api/leads/{id},/api/tasks/{id},/api/projects/{id}and/api/invoices/{id}answer{ "success": true, "data": { ... } }. - Others return the record itself with no envelope:
GET /api/companies/{id},/api/contacts/{id}and/api/deals/{id}.
Records are open objects. Endpoints often add related objects (a lead's stage or owner, for
example) and computed fields that the record schema does not list, and field-level permissions can
remove fields for some users. Treat a field you do not see as unavailable, not as null.
Errors have one shape across the API: { "error": "...", "code": "..." }, with an errorId on
server faults. See Errors.
Versioning
- Paths are not versioned: every endpoint lives under
/api/. - The OpenAPI document is version
1.0.0, and every operation in it is marked stable (x-apros-stability: stable). - Existing response shapes are kept as they are, because changing them would break the clients that already depend on them. That is why envelopes still differ between endpoints.
- Every workspace serves the current document at
GET /api/openapi.json. It needs no authentication and is the same for every workspace.
curl https://<your-workspace>.apros.app/api/openapi.jsonReading the reference
The reference uses three APROS-specific fields from the OpenAPI document:
| Field | What it tells you |
|---|---|
x-apros-scopes | The permissions the path enforces. The list is kept per path, not per method, so a GET may list the permission its sibling DELETE needs. A read needs only the read permission. |
x-apros-request-schema: "undocumented" | The endpoint validates the request body, but the body's schema is not published yet. A body the endpoint rejects comes back as 400 with the reason. |
x-apros-auth: "webhook-secret" | The operation is not called with an API key. It applies only to the inbound webhook endpoints. |