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.
Update fields on existing catalog objects
const url = 'https://api.eu1.luigisbox.ai/index/v1/example/index/';const options = { method: 'PATCH', headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'}, body: '{"objects":[{"@group_id":"example","@group_primary":true,"@id":"example","@title":"example","@type":"example"}]}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request PATCH \ --url https://api.eu1.luigisbox.ai/index/v1/example/index/ \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "objects": [ { "@group_id": "example", "@group_primary": true, "@id": "example", "@title": "example", "@type": "example" } ] }'Update individual fields on existing objects.
Answers 202 when every object is accepted and 207 when some are rejected, listing
them in rejected_objects. When every object is rejected, answers 422, or 503
when only internal failures rejected them.
Authorizations
Section titled “Authorizations ”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”Request Body required
Section titled “Request Body required ”Request body for partial field update.
object
Objects with the fields to change.
A partial catalog object where omitted fields stay unchanged.
object
Whether this product is the preferred product in its variant group.
Typed identifier of the object, <type>/<value>.
New display title of the object. Cannot be cleared: null or a blank string is rejected.
Object type; must match the type prefix of @id.
Example generated
{ "objects": [ { "@group_id": "example", "@group_primary": true, "@id": "example", "@title": "example", "@type": "example" } ]}Responses
Section titled “ Responses ”Every object of the batch was accepted; rejected_objects is empty.
Outcome of a write batch of which at least one object was accepted, or that was empty.
The status code tells the two apart: 202 when every object was accepted, 207
when rejected_objects lists the ones that were not.
object
Objects accepted for asynchronous processing.
Objects rejected; none of them will be applied.
Every rejected object with the reason it was rejected; empty when every object was accepted.
An object of a write batch that was rejected, and why.
object
@id of the rejected object, as sent.
@type of the rejected object, as sent.
Why the object was rejected, as a stable identifier. Clients switch on this; message is for humans and may be reworded. When an object has several problems, the code names the first one found and message describes the problems found, up to ten, and counts the rest. internal_error means the object itself may be fine and sending it again later may succeed. The set of codes is closed; a new one is announced as a contract change.
Zero-based position of the rejected object in the request’s objects array, which tells apart two objects of the batch that share an @id.
Why the object was rejected, for humans. May be reworded at any time.
Example
{ "rejected_objects": [ { "code": "title_missing" } ]}Some objects of the batch were accepted for asynchronous processing and some were not. Still a success status, so a client that only checks for 2xx sees it as one: read rejected_objects for the objects that were not accepted.
Outcome of a write batch of which at least one object was accepted, or that was empty.
The status code tells the two apart: 202 when every object was accepted, 207
when rejected_objects lists the ones that were not.
object
Objects accepted for asynchronous processing.
Objects rejected; none of them will be applied.
Every rejected object with the reason it was rejected; empty when every object was accepted.
An object of a write batch that was rejected, and why.
object
@id of the rejected object, as sent.
@type of the rejected object, as sent.
Why the object was rejected, as a stable identifier. Clients switch on this; message is for humans and may be reworded. When an object has several problems, the code names the first one found and message describes the problems found, up to ten, and counts the rest. internal_error means the object itself may be fine and sending it again later may succeed. The set of codes is closed; a new one is announced as a contract change.
Zero-based position of the rejected object in the request’s objects array, which tells apart two objects of the batch that share an @id.
Why the object was rejected, for humans. May be reworded at any time.
Example
{ "rejected_objects": [ { "code": "title_missing" } ]}Missing or invalid credentials
Canonical error body — every non-2xx response uses this shape.
object
Machine-readable error context; empty object when there is nothing to add.
object
Stable machine code naming why a well-formed request was refused: snake_case, prefixed by its domain — e.g. filter_unknown_field or cursor_mismatch. Safe to branch on; reason is not. Absent when the status code says all there is to say.
Every field-level problem found in the request, when validation is what failed. Absent when the rejection is not about a specific value.
One field-level reason a request was rejected.
object
Path to the offending value from the request root, e.g. ["body", "filters", 0, "operator"].
What is wrong with the value at loc.
Stable machine code for the problem, e.g. missing or string_too_short.
Human-readable, actionable error message.
Example generated
{ "exception_details": { "error_code": "example", "validation_errors": [ { "loc": [ "example" ], "msg": "example", "type": "example" } ] }, "reason": "example", "request_id": "example"}Authenticated but not permitted
Canonical error body — every non-2xx response uses this shape.
object
Machine-readable error context; empty object when there is nothing to add.
object
Stable machine code naming why a well-formed request was refused: snake_case, prefixed by its domain — e.g. filter_unknown_field or cursor_mismatch. Safe to branch on; reason is not. Absent when the status code says all there is to say.
Every field-level problem found in the request, when validation is what failed. Absent when the rejection is not about a specific value.
One field-level reason a request was rejected.
object
Path to the offending value from the request root, e.g. ["body", "filters", 0, "operator"].
What is wrong with the value at loc.
Stable machine code for the problem, e.g. missing or string_too_short.
Human-readable, actionable error message.
Example generated
{ "exception_details": { "error_code": "example", "validation_errors": [ { "loc": [ "example" ], "msg": "example", "type": "example" } ] }, "reason": "example", "request_id": "example"}Nothing was applied. Either the body failed validation, which exception_details.validation_errors describes, or it was well-formed and every object in it was rejected, which exception_details.rejected_objects lists with a code for each.
The error body of a rejected write batch.
Its exception_details carry exactly one of validation_errors, when the body is
malformed, and rejected_objects, when the body is well-formed but every object in
it was rejected.
object
Machine-readable error context; empty object when there is nothing to add.
object
Stable machine code naming why a well-formed request was refused: snake_case, prefixed by its domain — e.g. filter_unknown_field or cursor_mismatch. Safe to branch on; reason is not. Absent when the status code says all there is to say.
Objects rejected. Present, with rejected_objects, only when the body was well-formed and every object in it was rejected; absent when validation_errors is present.
Every rejected object with its code and reason. Present only when the body was well-formed and every object in it was rejected; absent when validation_errors is present. Exactly one of the two is present.
An object of a write batch that was rejected, and why.
object
@id of the rejected object, as sent.
@type of the rejected object, as sent.
Why the object was rejected, as a stable identifier. Clients switch on this; message is for humans and may be reworded. When an object has several problems, the code names the first one found and message describes the problems found, up to ten, and counts the rest. internal_error means the object itself may be fine and sending it again later may succeed. The set of codes is closed; a new one is announced as a contract change.
Zero-based position of the rejected object in the request’s objects array, which tells apart two objects of the batch that share an @id.
Why the object was rejected, for humans. May be reworded at any time.
Every field-level problem found in the request. Present only when the body failed validation; absent when rejected_objects is present. Exactly one of the two is present.
One field-level reason a request was rejected.
object
Path to the offending value from the request root, e.g. ["body", "filters", 0, "operator"].
What is wrong with the value at loc.
Stable machine code for the problem, e.g. missing or string_too_short.
Human-readable, actionable error message.
Example
{ "exception_details": { "rejected_objects": [ { "code": "title_missing" } ] }}Catalog ingestion is unavailable, or an internal failure prevented processing every object of the batch. Part of the batch may still have been applied; sending it again unchanged is safe. Send it again after Retry-After.
Canonical error body — every non-2xx response uses this shape.
object
Machine-readable error context; empty object when there is nothing to add.
object
Stable machine code naming why a well-formed request was refused: snake_case, prefixed by its domain — e.g. filter_unknown_field or cursor_mismatch. Safe to branch on; reason is not. Absent when the status code says all there is to say.
Every field-level problem found in the request, when validation is what failed. Absent when the rejection is not about a specific value.
One field-level reason a request was rejected.
object
Path to the offending value from the request root, e.g. ["body", "filters", 0, "operator"].
What is wrong with the value at loc.
Stable machine code for the problem, e.g. missing or string_too_short.
Human-readable, actionable error message.
Example generated
{ "exception_details": { "error_code": "example", "validation_errors": [ { "loc": [ "example" ], "msg": "example", "type": "example" } ] }, "reason": "example", "request_id": "example"}Headers
Section titled “Headers ”Seconds to wait before sending the request again.
Was this page helpful?
Thanks.