Multi Entity Request

Fetches data for multiple entities in a single request. The request body is a JSON array of sub-requests; each sub-request independently reads one entity — either a single record (show) or a filtered list (list).

POST /v2/api/multi-entity

The response is a single JSON object whose keys are each sub-request's alias (or its key when no alias is given). Each value holds that sub-request's result, so one call can return, for example, an invoice together with its related requisitions.

Sub-request fields

Field	Required	Description
key	Yes	The entity key to read (e.g. `invoice`, `requisition`, `follow_up_reminder`).
action	Yes	`show` to fetch a single record, `list` to fetch a filtered list. Any other value returns `{ "error": "Action not found" }` under that alias.
options	Yes	Depends on `action`. For `show`: the record id. For `list`: a filters object (see below).
alias	No	The key under which this sub-request's result appears in the response. Defaults to `key`. Use it to disambiguate two sub-requests that read the same entity.
level	No	Data-detail level — how deeply related records are loaded. Defaults to `1`. Higher levels return more nested relations.

`options` by action

show — options is the record id, e.g. "options": "172185".

list — options is an object of filter conditions merged into the listing query, e.g. "options": { "order_id": "172185", "order_type": 3 }. Any field the target entity supports may be used.

Response

Always returns HTTP 200. The body is an object keyed by each sub-request's alias:

A show sub-request → the record object (with a custom_data property holding the record's custom-field values, when the entity has any).

A list sub-request → a paginated envelope (data array plus current_page, per_page, total, last_page, and page-URL fields).

A failed sub-request → { "error": "<message>" }.

Sub-requests are processed independently: a failure in one (unknown action, inactive plugin, no permission to view the record, or an otherwise invalid sub-request) is reported as an error object under that alias and never fails the whole call. The overall HTTP status is always 200.

Permissions: a show sub-request requires permission to view the requested entity; without it that alias returns { "error": "You are not allowed to view this page" }.

Authentication

Send an OAuth Bearer access token in the Authorization header. Also send Accept: application/json.

Provide your bearer token in the

Authorization

header when making requests to protected resources.

Example:

Authorization: Bearer ********************

Responses

🟢200Success

application/json

Always returned, even when individual sub-requests fail. The body is an object keyed by each sub-request's alias.

Example body for the request example above (an invoice fetched by show and its requisitions fetched by list):

{
  "invoice": {
    "id": 172185,
    "no": "INV-000123",
    "custom_data": null
  },
  "requisition": {
    "current_page": 1,
    "data": [ { "id": 991, "order_id": 172185, "order_type": 3 } ],
    "per_page": 20,
    "total": 1,
    "last_page": 1
  }
}

A sub-request that fails appears as an error object under its alias, e.g. { "requisition": { "error": "You are not allowed to view this page" } }.

Bodyapplication/json

🟠401Unauthorized

curl --location --globoff 'https://.daftara.com/v2/api/multi-entity' \ --header 'Accept: application/json' \ --header 'apikey: ' \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '[ { "key": "invoice", "action": "show", "options": "172185", "level": 2 }, { "key": "requisition", "action": "list", "options": { "order_id": "172185", "order_type": 3 }, "alias": "requisition" } ]'

Multi Entity Request

Sub-request fields#

options by action#

Response#

Authentication#

Request

Responses

Sub-request fields

`options` by action

Response

Authentication