Skip to main content
Four endpoints take a batch instead of a single item. They share one response envelope, and one habit: read failed_count, not the HTTP status. A batch costs 1 against your quota, however many items it contains. That is the main reason to use these endpoints. Every batch is 1–100 elements.

The response

The status is always 200, including when every element failed.
Check failed_count, not the HTTP status. A client that only checks response.ok will read a 200 full of failures as a success.
index is the position in the array you sent — for creation it is the only way to match a result back to your data. Creation and group operations return the resource in the flat list form, not the card. Deletion returns { id, object, deleted: true }.

Per-element errors

failed[].error has no HTTP status — only code, message and value. value is always present, null where there is nothing to point at. Offending data is not interpolated into message; read it from value.

What fails the whole request instead

Malformed input is rejected wholesale with 400: a bad prefix, a non-hex id, a batch that is too large or empty. Two more cases go the same way:
  • An unknown country code. Every unrecognised code is listed in details.
  • The group in the path. Unknown or not yours returns 404 group_not_found, since no element can be carried out without it.
Duplicates within a batch are treated per element, not as malformed input.

Fitting plan limits

When creating entities in bulk that are subject to limits, it’s important to understand how we handle them. We don’t reject the entire request if your current number of links plus N exceeds your plan limit. Instead, the system creates as many entities as allowed, in the order they were provided. The remaining ones will fail with plan_limit_reached.