Object history

Pre-launch API. The concepts described here are settled, but the API shape is not: request and response fields, parameters and defaults can still change. Build against it, and talk to your Luigi's Box contact before you put an integration into production.

Indexing is asynchronous. The timeline endpoint lists every change Luigi’s Box received for a single object, in order, each marked as applied or still in flight.

Request

curl -G 'https://api.eu1.luigisbox.ai/ledger/v1/catalogs/lbc_8w3k2p/objects/product/sku-1001/timeline' \
  --data-urlencode 'date_from=2026-03-01T00:00:00Z' \
  -H 'Authorization: Bearer <token>'

Parameter	Required	Notes
`catalog_id`	Path	The catalog
`public_id`	Path	The object’s identity — `product/sku-1001`, slash included
`date_from`	Query	Start of the window. Omit for the whole retained history.

The identity sits in the path with its type prefix and its slash, unescaped:

/ledger/v1/catalogs/lbc_8w3k2p/objects/product/sku-1001/timeline

The window always runs from date_from to now. Needs a token for the https://api.<region>.luigisbox.ai/ledger audience, and a grant to read the catalog’s change history.

Response

{
  "catalog_id": "lbc_8w3k2p",
  "identity": "product/sku-1001",
  "window": { "date_from": "2026-03-01T00:00:00Z", "to": "now" },
  "entries": [
    {
      "event_id": "01JQ8H3Z9K2F7M4N6P8R0S2T4V",
      "timestamp": "2026-03-14T11:42:08Z",
      "operation": "partial_update",
      "status": "pending",
      "source_system": "content-api",
      "payload": { "price": 24.9 }
    },
    {
      "event_id": "01JQ8G1M5X8B3C6D9E2F4G7H0J",
      "timestamp": "2026-03-14T02:03:51Z",
      "operation": "update",
      "status": "acked",
      "source_system": "feed-processor",
      "payload": { "@title": "Blue Cotton T-Shirt", "price": 29.9, "availability": 1 }
    }
  ]
}

Entries are newest first.

Field	Meaning
`timestamp`	When Luigi’s Box received the change
`operation`	`update` (full upsert), `partial_update`, or `delete`
`status`	`acked` — applied and searchable. `pending` — received, not yet applied.
`source_system`	Where the change came from — a feed run, or an API call
`payload`	The change as received
`event_id`	Identifier for this change. Quote it in support requests.

Reading it

Whether an update was applied. Find the change by timestamp and read its status. acked means it is applied. pending on a change from seconds ago is normal; pending on a change from an hour ago is worth reporting to support.

A product still shows the old value. Look at the newest entry. If a later full update followed your partial_update, it replaced the whole object — including your field. A full upsert stores exactly what it was sent.

This means one object type is being written from two places — typically a feed run overwriting a change the API had made. Give the content one owner: either the feed carries the live value, or the Content API owns the object outright. See Content API.

Where a change came from. source_system distinguishes a feed run from an API call. If a field you own by API keeps reverting, source_system names what is reverting it.

A product disappeared. A delete entry says when, and from where. A feed processing a snapshot deletes what the snapshot omits — so a delete from a feed run usually means the record fell out of your export.

What it does not do

It covers one object at a time. There is no bulk or catalog-wide timeline; the path takes a single identity.
History is retained for a window, not forever. date_from cannot reach further back than what is retained.
payload is what was received, not what is stored. To see the object as it is now, fetch it with object lookup.