## TL;DR

HubSpot batch endpoints return HTTP 200 with per-item statuses inside, so a "successful" call can hide failed items. Iterate the results array, check each item's status, and route failures to retry with their reasons. The HTTP code lies; the items tell the truth.

## Error

```text
(No error; the symptom is a 200 batch response with some records never updated and no failure surfaced.)
```

## Steps

1. Parse the response's results array (not just the status code). Expected: per-item outcomes.
2. For each item, check its status field; collect the non-success items. Expected: the true failure list.
3. Group failures by their error messages. Expected: a handful of classes.
4. Retry the failed items (individually or in a smaller batch) after fixing each class. Expected: failures clear.
5. Change the agent to always inspect per-item status on batch calls. Expected: partial failures never hide again.

## When to use

- Batch calls return 200 but items are missing updates.
- An agent assumes HTTP 200 means all succeeded.
- After batching, some records never change.

## When not to use

- Whole-batch 400s or 429s (those are honest HTTP errors).
- Single-record endpoints (no partial success possible).

## Tool compatibility

- HubSpot batch endpoints (v3/v4); per-item status fields.
- Agent batch handling.

## Variant phrasings

### partial success hidden in 200

Inspect per-item status.

### batch "succeeded" but items missing

Same fix from the data side.

## Why it happens

Batch APIs optimize for throughput: one HTTP round trip, many logical operations. The HTTP status can only describe the transport, so item outcomes live in the body.

## Edge cases

- Some items fail with rate-limit errors while others succeed; retry only the failed.
- Error formats differ between batch endpoints; read each endpoint's docs.
- Timeouts can leave item state unknown; verify before retrying writes.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_icTAhDnXmrILdZkg3oklSQ