How do you design tests for a feature that integrates with a third-party API you cannot control?

You cannot assume a third-party API is available, consistent, or behaves as documented. The test design must account for this.

Happy path against a sandbox or stub. Most serious third-party APIs provide a sandbox environment or documented test accounts. Run your functional tests there — do not use production third-party environments in CI.

Full error coverage against a mock. Use WireMock, MSW, or equivalent to simulate every failure mode the third party documents: 400, 401, 403, 429 (rate-limited), 500, timeout, malformed JSON. These are the cases your error handling code must deal with — and they are impossible to trigger reliably in a real environment.

Consumer-driven contract tests. Define the minimum response shape your code depends on and verify it against the real API in a scheduled test run (not every PR). If the third party changes a field, contract tests catch it before production does.

Resilience tests. Inject latency and chaos into the stub to verify your retry logic, circuit breaker, and timeout configuration behave correctly under degraded third-party conditions.