Synkronisering

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.