Claude Code for API integrations: what to verify before shipping

Claude writes API integration code quickly. It also writes code based on the version of an API that was in its training data, which may not be the current version. And it makes assumptions about error behavior that the actual API may not match.

Here's what to check before any API integration code goes to production.

Tell Claude the API version explicitly

Before asking Claude to write any API integration: "The API version is X. Read the docs at [URL] if you need to check anything." If you don't specify a version, Claude uses whichever version it saw most in training. For many popular APIs, that's an older version.

For internal or less-common APIs: paste the relevant section of the docs directly into the prompt. Claude can't look these up, and guessing from the client library alone misses undocumented behavior.

Error response shapes

The biggest source of bugs in Claude-generated API code: the error handling assumes a response shape that doesn't match what the API actually returns. Claude writes error.message when the API returns error.errors[0].detail. It handles 401 and 403 the same way when the API distinguishes them differently.

After Claude writes any API error handling: verify the error shapes against actual API responses or docs. Don't trust Claude's assumptions here.

Rate limits and retry logic

Claude writes retry logic that is structurally reasonable but often has wrong backoff values, wrong retry counts, or handles rate limit responses incorrectly for the specific API. "Retry on 429 with exponential backoff" is the pattern, but the implementation details vary.

Check: does the retry logic read the Retry-After header if the API provides one? Does it cap total wait time? Does it differentiate between rate limit errors and service errors?

Authentication edge cases

Claude handles auth token expiry inconsistently. It might refresh a token on 401 but not retry the failed request. It might not handle token refresh failure. It might not handle the case where refresh returns a 200 but the new token is malformed.

Sketch out your auth flow on paper before asking Claude to implement it. Then verify the implementation against the sketch. The happy path will be correct. The edge cases need checking.

The integration test you actually need

After Claude writes an integration: write one test that makes a real call against a sandbox or test environment (not mocks). Mocked tests confirm the code is internally consistent, not that it works with the actual API. One real call catches the version mismatch and wrong error shapes that mocked tests miss.