A thorough pull request review of a new external API integration covers five areas: credential safety, error handling, data security, test coverage, and a local run of the integration itself. Done carefully, the full review takes between 45 minutes and two hours depending on the complexity of the call chain.
This guide is for the developer sitting down with the diff open. You've been asked to review a PR that adds a call to a third-party API, maybe a payment provider, an SMS gateway, or a mapping service, and you want to catch every real problem before it reaches production.
What you need before you start
Before opening the diff, gather three things: the PR description, any linked ticket or spec, and local access to the codebase so you can run the integration yourself.
If the description is thin or missing, ask the author to add the endpoint base URL, the auth method, and a summary of what triggers the call. Reviewing without that context wastes everyone's time. You don't need to be an expert in the third-party API, but you do need its public docs open in a second tab. Rate limits, deprecation notices, and error response shapes are all in there, and you'll refer to them throughout the review.
1. Map what the integration actually does
Read the PR description and linked ticket first, then open the diff and trace every file the new integration touches, from the trigger point to the response handler.
Sketch or mentally note the call chain: what fires the request, what parses the response, what happens on failure. Look for side effects the description didn't mention, such as a webhook registration, a background job, or a new environment variable. Those belong in the PR description if they're not already there.
When you've finished this step, you should be able to state in one sentence what the integration does and name every layer of the stack it touches. If you can't, the diff is incomplete or the description needs work before the pull request review goes further.
2. Check credentials, auth, and secrets
API keys, tokens, and client secrets must never appear in source code, config files committed to the repo, or log output. Check that credentials are loaded from environment variables or a secrets manager, not hardcoded or defaulted to a real value.
Confirm that tokens are scoped to the minimum permissions the integration needs. A read-only token has no business having write access. Look at the headers being sent. If the API uses OAuth, confirm the token refresh path is handled and that expired-token errors don't silently fail.
When this step passes, no credential is visible in the diff and every secret has a documented name in the project's environment variable list.
3. Review error handling and failure modes
Unhandled failure paths in external API calls are among the most common causes of production incidents. Work through them in three passes.
3a. Check every non-200 response path
Every HTTP status the API can return needs a handling decision: retry, surface to the user, log and continue, or fail hard. An unhandled 429 or 503 will become a production incident. Cross-reference the API docs to confirm you've seen every status the endpoint documents.
3b. Check timeouts and retries
The code must set an explicit timeout on the HTTP client, not rely on a platform default. Confirm retries use exponential backoff and cap at a sensible maximum. Also confirm that retries are not triggered on 4xx errors, which are permanent failures and will loop indefinitely if not excluded.
3c. Check what the caller sees when the API is down
Trace what a user or upstream service receives if the external call fails completely. A generic 500 with no context is hard to debug. A clear error message or a graceful degraded state is the target outcome for this step. If you're not sure what a clear, actionable comment looks like here, this breakdown of what makes a code review comment actionable is worth a few minutes.
4. Audit data handling and security
Any data the integration sends to a third party or receives from one is a potential attack surface and a potential compliance issue.
Check whether the PR sends personal data to the API. If it does, confirm that's permitted under the product's privacy policy and any applicable regulation. Look at how the response payload is parsed. If the code deserialises JSON directly into an object with no schema validation, a malformed or malicious response can corrupt state. The review should confirm the code validates shape and type before using values.
Check that the base URL is not configurable by user input. An open redirect through an external API call is a server-side request forgery risk. When this step is done, you can confirm that no unexpected personal data leaves the system and that the response parser rejects unexpected shapes. Spotting logic bugs in a pull request before they hit production covers the broader category of subtle mistakes that security audits often surface alongside these checks.
5. Test the integration and approve or request changes
Reading the diff is not enough. You need to run the code.
5a. Run the integration locally or in a staging environment
Pull the branch, set up the required environment variables using the API's sandbox credentials, and trigger the integration manually. Confirm the happy path works, then simulate a failure by pointing at a bad endpoint or revoking the token. The fallback behaviour you reviewed in step 3 should match what you see.
5b. Check the test coverage in the PR itself
The PR should include unit tests that mock the external API and cover at least the success path, a timeout, and a non-200 error. If those tests are missing, request them before approving. Integration tests against a sandbox are a bonus but not always required.
5c. Approve, request changes, or comment
If every check above passes, approve. If anything is blocking, request changes with a specific description of what needs to change and why. A comment that says "add error handling" is less useful than "the 429 response from this endpoint is not handled; the call should retry with backoff or surface a user-facing message". Clear feedback means a faster second round.
Frequently asked questions
How do you test a pull request for an external API integration?
Pull the branch locally, configure the API's sandbox credentials as environment variables, and trigger the integration manually. Test the success path, then simulate failures by using a bad endpoint or an invalid token. The PR's own unit tests should mock the external API and cover at least a timeout and a non-200 response.
What should a pull request description include for an API integration?
At minimum: the endpoint base URL, the authentication method, what triggers the call, and any side effects like new environment variables or background jobs. A short summary of failure behaviour is also helpful. Reviewers who have that context can focus on the code rather than reconstructing intent from the diff.
Should a reviewer approve a PR with missing tests?
Generally no, not if the missing tests cover the success path or known failure modes. Request the tests before approving. You can approve with a comment for minor gaps, but missing coverage on error handling in an external integration is a blocking issue.