/deletions
List deleted records
Returns records that have been deleted, so an incremental sync can retire its local copies. This endpoint exists because a deletion cannot be observed from the list endpoints.
Show the full description
When a customer, supplier, purchase order or configuration is deleted the row is really gone, so no filter on GET /preview/customers (or any other collection) can surface it — it simply stops appearing, which is indistinguishable from "unchanged since your last poll". Every deletion is recorded here instead, in the same transaction as the deletion itself. Covers: `customers`, `items`, `suppliers`, `orders`, `purchase-orders`, `configurations`, `quotes`, `returns`, `shipments`, `invoices`. Filter to one collection with `?resource=` (an unknown value returns 400 rather than an empty page). **Running a sync.** Poll `?modifiedSince=` on the list endpoints for creates and updates, and `?deletedSince=` here for removals, using the same timestamp for both. Results are sorted by `deletedDate` ascending, so take the highest `deletedDate` you have seen and pass it as the next `?deletedSince=`. Re-reading from a slightly earlier timestamp is safe: applying a deletion twice has no further effect. `businessKey` is the identifier the record had when it was deleted — customer number, item number, order number. It is normally the field you stored, so match on it; `id` is there for clients that keyed on the GUID instead. Omitting `?deletedSince=` returns the full log from the beginning, which is rarely what you want after the first sync. Paginated response: `{ items, totalCount, page, pageSize, totalPages, hasPreviousPage, hasNextPage }`. `?page=` defaults to 1, `?pageSize=` to 50 and is capped at 200.
Query parameters
| Field | Type | Description |
|---|---|---|
deletedSince
|
string(date-time) | Returns only records deleted at or after this instant (ISO 8601 UTC datetime). Omitting it returns the whole log from the beginning. |
resource
|
string | Limits the log to one collection, given by its path segment such as customers or purchase-orders. An unknown value returns 400 rather than an empty page. |
page
|
integer | Page to return, 1-based. Default 1. |
pageSize
|
integer | Number of records per page. Default 50, max 200. |
Responses
PagedResult_PublicDeletionResponse
Paginated response: the fields below sit in items[], wrapped in totalCount, page, pageSize, totalPages, hasPreviousPage and hasNextPage. Paginated
| Field | Type | Description |
|---|---|---|
businessKey
|
string · nullable | The business key the record had when it was deleted — customer number, item number, order number. This is normally what you stored on your side, so it is the field to match on. Null when the record never had one (an unnumbered draft, for example). |
deletedDate
|
string(date-time) | UTC timestamp of the deletion. Use the highest value you have seen as the next `?deletedSince=`. |
id
|
string(uuid) | The deleted record's `id`, the same value its list endpoint used to return. |
resource
|
string · nullable | Which collection the record belonged to: `customers`, `items`, `suppliers`, `orders`, `purchase-orders` or `configurations`. Matches the path segment of the list endpoint the record used to appear in. |
ProblemDetails
?resource= names a collection that is not covered by the deletion log.
| Field | Type |
|---|---|
detail
|
string · nullable |
instance
|
string · nullable |
status
|
integer · nullable |
title
|
string · nullable |
type
|
string · nullable |
Standard errors:
401
403
Errors
Examples
curl "https://api.erp.fluit.cloud/preview/deletions" \
-H "X-Api-Key: fluit_live_sk_..."{
"hasNextPage": true,
"hasPreviousPage": true,
"items": [
{
"businessKey": "string",
"deletedDate": "2026-06-11T09:24:13.418",
"id": "0f8b2c1e-4d3a-4b7e-9f10-2a6c5d8e1b44",
"resource": "string"
}
],
"page": 1,
"pageSize": 50,
"totalCount": 137,
"totalPages": 3
}Base URL https://api.erp.fluit.cloud/preview. The response example is generated from the schema: the shape is right, the values are made up.