ObjectAPI
Querying Enterprise Documents
Introduction
The Unit4 ERPx Object API plays a crucial role in many Unit4 ERPx integrations. These endpoints provide flexible, efficient access to Enterprise Documents - the core business entities that power Unit4 ERPx. They return an array of structured JSON documents known as Enterprise Documents. Enterprise Documents have a set of properties often structured in functionally meaningful groups. Property names across different Enterprise Documents are governed by an ontology, ensuring that the same name is mapped to the same business meaning.
Sample request
Below, a sample request and its response are shown for the Customers endpoint:
curl -X GET \
"https://unit4-api-address/v1/objects/customers\
?companyId=EN\
&select=companyId,customerId,customerName,invoice(creditLimit,currencyCode)\
&filter=customerId%20eq%20%271001%27" \
-H "Authorization: Bearer YOUR_TOKEN_HERE" \
-H "Accept-Encoding: gzip"
[
{
"companyId": "EN",
"customerId": "1001",
"customerName": "Smith & Jones Industries Ltd.",
"invoice": {
"creditLimit": 300000.000,
"currencyCode": "GBP"
}
}
]customerId eq ‘1001’.Endpoints
For each Enterprise Document, there is an ObjectAPI endpoint. These endpoints are always in the format /v[?]/[enterprise-document-name-plural-form], where [?] represents the version of the Enterprise Document. A new version is created if a breaking change is introduced.
Each endpoint has the same standard set of query parameters:
| Parameter | Description |
|---|---|
| select | Used for vertical sectioning, retrieve only the required properties |
| filter | Used for horizontal filtering, only retrieve the required Enterprise Documents |
| orderBy | Control the order in which the Enterprise Documents are returned |
| limit | Control the maximum number of Enterprise Documents returned for this request |
| offset | Skip the first x Enterprise Documents from the response |
| companyId | Controls for which company Enterprise Documents are returned |
Some endpoints might have additional query parameters that control the transactional state of the Enterprise Document. For example, in the case of GeneralLedgerTransactions, we have the additional query parameters registered, posted, and historical. These are boolean values, and at least one state needs to be requested. If they are not provided, the API will respond with a 400 status code, including an error message in the response body describing what needs to be done.
{
"code": 1020,
"message": "At least one of the parameters 'registered', 'posted', 'historical' should be set to 'true'"
}