Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_BACK/llms.txt

Use this file to discover all available pages before exploring further.

Most Dragon Guard list endpoints return paginated responses to keep payloads manageable for both handheld scanner devices on slow warehouse networks and back-office clients that may be processing thousands of records. Rather than returning all matching records in a single call, the API divides results into pages and tells you exactly how many total records and pages exist so your client can navigate the full dataset efficiently.

Query Parameters

All paginated endpoints accept the following query parameters defined in PaginationParameters:
pageNumber
integer
default:"1"
The 1-based page number to retrieve. Values less than 1 are automatically clamped to 1.
pageSize
integer
default:"20"
The number of records to return per page. The default is 20 for most endpoints. The hard maximum enforced by PaginationParameters is 100; any value above 100 is silently clamped to 100.
Some endpoints override the default pageSize. For example, GET /api/audit/logs defaults to pageSize=25. Check the individual endpoint reference for endpoint-specific defaults.

PagedResponse Wrapper

Every paginated endpoint wraps its result set in a PagedResponse<T> object:
data
array
required
The array of result objects for the current page. The element type varies by endpoint (e.g., items, bins, audit log entries).
pageNumber
integer
required
The page number that was returned (mirrors the requested pageNumber).
pageSize
integer
required
The number of records per page that was applied (mirrors the effective pageSize after clamping).
totalRecords
integer
required
The total count of records matching the applied filters across all pages.
totalPages
integer
required
The total number of pages: ceil(totalRecords / pageSize). Returns 0 when there are no matching records.

Example Response

The following is a representative paged response for a warehouse items list:
{
  "data": [
    {
      "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "sku": "DRG-00142",
      "description": "Pallet Jack — 2500 kg",
      "companyId": "a1b2c3d4-0000-0000-0000-111122223333",
      "isActive": true
    },
    {
      "id": "7cb91e02-1234-4321-abcd-aabbccddeeff",
      "sku": "DRG-00143",
      "description": "Hand Wrap Dispenser",
      "companyId": "a1b2c3d4-0000-0000-0000-111122223333",
      "isActive": true
    }
  ],
  "pageNumber": 1,
  "pageSize": 20,
  "totalRecords": 143,
  "totalPages": 8
}

Iterating Through All Pages

To retrieve the full result set, increment pageNumber by one on each successive request until the page you received equals totalPages.
# Page 1
GET /api/items?pageNumber=1&pageSize=50
Authorization: Bearer <token>

# Page 2
GET /api/items?pageNumber=2&pageSize=50
Authorization: Bearer <token>

# Continue until pageNumber > totalPages
In pseudo-code:
page = 1
do:
    response = GET /api/items?pageNumber={page}&pageSize=50
    process(response.data)
    page += 1
while page <= response.totalPages
If a new record is inserted or deleted between page requests, totalRecords and totalPages may shift. For bulk exports that require consistency, consider filtering by a fixed date range or using a snapshot approach.

Anonymous Pagination Objects

Some older controllers in the Dragon Guard API return inline anonymous objects rather than the typed PagedResponse<T> class. These objects carry the same field names (data, pageNumber, pageSize, totalRecords, totalPages) and follow the same pagination contract, so client-side deserialization code does not need to distinguish between the two shapes.

Audit Logs Pagination

The /api/audit/logs endpoint follows the same pageNumber / pageSize pattern. Its defaults differ slightly:
ParameterDefaultMaximum
pageNumber1
pageSize25100
See the Auditing reference for the full list of filter parameters available on that endpoint.
For handheld scanners operating over warehouse Wi-Fi or cellular data, start with pageSize=20 or pageSize=50. Very large pages (e.g., pageSize=100) increase response latency and memory pressure on constrained devices, and may time out on slow connections.
Use totalPages rather than totalRecords to drive your loop termination condition. This avoids off-by-one errors when totalRecords is not evenly divisible by pageSize.

Build docs developers (and LLMs) love