>_ API Integration Testing Checklist

Short answer

An API Integration Testing Checklist is a list of checks that helps verify whether two or more systems exchange data correctly through APIs as part of a real business workflow.

This checklist does not replace an API Testing Checklist. API testing checks whether an API endpoint works correctly. API integration testing checks whether two or more systems exchange data correctly through APIs in a real business workflow.

For example:

• an e-commerce store sends an order to an ERP;
• checkout sends payment data to a payment provider;
• a SaaS app creates a lead in a CRM;
• a booking platform sends a reservation to an external calendar;
• a support form creates a ticket in a helpdesk tool;
• an internal tool syncs users with an identity provider;
• a warehouse system receives a fulfillment request;
• an external system sends a webhook back to the product.

API integration testing checks more than whether an endpoint returns 200 or 201. It checks that:

• System A sends the correct data;
• System B receives the correct data;
• fields are mapped correctly;
• OAuth, API keys, or tokens work;
• sandbox and production URLs are not mixed up;
• retries and timeouts do not create duplicates;
• webhooks and callbacks are delivered;
• external API errors are handled;
• rate limits do not break the workflow;
• statuses are synchronized;
• data matches across both systems;
• logs and monitoring help the team understand where the integration failed.

The main idea is: API integration testing answers the question “does the business process between systems work correctly through APIs?”

---

API Integration Testing vs API Testing

API Testing checks the API endpoint itself.

For example:

• POST /orders returns 201;
• required fields are validated;
• unauthorized user receives 401;
• forbidden user receives 403;
• response schema is correct;
• invalid request does not return 500;
• endpoint saves data correctly.

API Integration Testing checks the connection between systems.

For example:

• e-commerce order appears in ERP;
• payment provider returns successful payment status;
• CRM receives a lead with correct fields;
• webhook updates order status;
• retry does not create a duplicate order;
• failed external API request is saved for retry;
• data matches in the source system and target system;
• support team can find integration failure in logs.

In simple terms:

API Testing: “Does the endpoint work correctly?” API Integration Testing: “Does the whole cross-system workflow work through APIs?”

---

API Integration Testing vs End-to-End Testing

API integration testing and end-to-end testing overlap, but they are not the same thing.

End-to-end testing usually checks the full user journey:

• user opens the UI;
• fills out a form;
• clicks submit;
• goes through checkout;
• sees confirmation;
• receives email.

API integration testing focuses on data exchange between systems inside or after that journey:

• form submission created a lead in CRM;
• checkout created a payment intent;
• payment provider sent a webhook;
• order status was updated;
• ERP received the order;
• warehouse received the fulfillment request;
• email system received the correct payload.

For example, an E2E test may confirm that the user saw “Order confirmed.”

An API integration test should confirm that this order actually appeared in the payment provider, ERP, fulfillment system, and admin panel with correct data.

---

API Integration Testing vs Webhook Testing

Webhook testing is part of API integration testing, but it is not the whole integration.

Webhook testing checks event delivery:

• webhook was sent;
• webhook was received;
• signature was verified;
• duplicate webhook was handled;
• status was updated;
• failure was logged.

API integration testing is broader. It covers:

• initial API request;
• authentication;
• data mapping;
• business workflow;
• external API response;
• retries;
• timeouts;
• rate limits;
• callbacks;
• webhooks;
• reconciliation;
• logs;
• monitoring;
• support visibility.

A webhook can work perfectly, but the integration can still be broken because of incorrect field mapping, sandbox URL, missing permission, stale status, or duplicate retry.

---

When to use an API Integration Testing Checklist

Use this checklist whenever a product exchanges data with another system through an API.

For example:

• a new external integration is added;
• CRM integration changes;
• payment provider changes;
• ERP sync is added;
• warehouse or fulfillment integration is added;
• shipping provider is added;
• email provider changes;
• identity provider or SSO is added;
• analytics integration is added;
• API keys or OAuth scopes change;
• webhook handling changes;
• callback URLs change;
• data mapping changes;
• retry logic is added;
• rate limit or timeout behavior changes;
• sandbox/production configuration changes;
• provider migration is being performed;
• there was a production incident: data did not arrive, arrived twice, went to the wrong place, or arrived with incorrect fields.

For a small configuration change, a short integration smoke test may be enough. For payment, order, CRM, ERP, fulfillment, identity, billing, or high-risk business workflows, it is better to go through the full API integration testing checklist.

---

Short API Integration Testing Checklist

If you need a minimal API integration smoke test, check that:

• integration scope is clear;
• source system and target system are defined;
• business workflow is documented;
• sandbox/production URLs are configured correctly;
• API keys, OAuth, or tokens work;
• required scopes and permissions are granted;
• test data is prepared in both systems;
• System A sends request to System B;
• System B receives the request;
• required fields are passed;
• field mapping is correct;
• IDs and external references are stored;
• date, time, and timezone are correct;
• currency and amounts are correct;
• target system creates or updates the expected record;
• status is synchronized back if needed;
• webhook or callback is delivered;
• duplicate webhook does not create duplicate record;
• timeout or retry does not create duplicate;
• external API error is handled clearly;
• rate limit does not break workflow;
• logs show request, response, correlation ID, and error;
• monitoring shows integration health;
• data matches in both systems;
• production integration smoke has passed after release.

This is not a full API Testing Checklist. It is a quick check that shows whether cross-system integration works at a basic level.

---

API Integration Testing Checklist

1. Define the integration scope

Before testing starts, understand exactly which integration is being checked.

Check that:

• participating systems are known;
• sending system is known;
• receiving system is known;
• business workflows in scope are defined;
• workflows outside scope are defined;
• API endpoints used by the integration are known;
• webhooks or callbacks used by the integration are known;
• events that trigger the integration are defined;
• records that should be created are known;
• records that should be updated are known;
• statuses that should be synchronized are known;
• critical integrations are identified;
• integration owner is known;
• pass / fail decision owner is known.

The main question is: which business process should work between systems through APIs?

---

2. Define the source system and target system

In integration testing, data direction matters.

Check that:

• source of action is defined;
• target system is defined;
• source of truth is defined;
• data flow is one-way or two-way;
• target system can or cannot update data back;
• sync conflict scenarios are known;
• records that should match are known;
• records that may differ are known;
• system responsible for final status is defined;
• system responsible for retry is defined;
• system responsible for error handling is defined.

For example, e-commerce may be the source of truth for the order, the payment provider may be the source of truth for payment status, and ERP may be the source of truth for fulfillment status.

---

3. Describe the business workflow

API integration testing should start with workflow, not endpoint.

Check that:

• user or system action that triggers the integration is known;
• expected event in the source system is clear;
• API request being sent is known;
• expected event in the target system is clear;
• expected response is known;
• expected side effects are known;
• webhook or callback expected in return is defined;
• final state in both systems is known;
• person or team using the integration result is known;
• successful integration is defined;
• failed integration is defined.

Example workflow:

1. User places order in e-commerce store.
2. Store creates order internally.
3. Store sends order to ERP.
4. ERP creates sales order.
5. ERP returns external order ID.
6. Store saves external order ID.
7. ERP later sends fulfillment status update.
8. Store updates order status for user.

---

4. Prepare integration environment

Many integration bugs are caused by configuration, not code.

Check that:

• sandbox environment is available;
• production environment is available if this is production smoke;
• source system points to the correct target environment;
• sandbox does not send data to production;
• production does not send data to sandbox;
• base URLs are correct;
• callback URLs are correct;
• webhook URLs are correct;
• API gateway routing is correct;
• feature flags are enabled;
• test mode is enabled where needed;
• environment variables are configured;
• there are no localhost URLs;
• there are no old domain URLs;
• there is no staging URL in production config.

One of the most dangerous mistakes is when staging sends real data to an external production system, or production still points to sandbox.

---

5. Prepare credentials and secrets

API integration almost always depends on credentials.

Check that:

• API keys are created;
• OAuth client ID and client secret are correct;
• bearer tokens work;
• refresh tokens work if used;
• service account is configured;
• credentials belong to the correct environment;
• production keys are not used in sandbox unnecessarily;
• sandbox keys are not used in production;
• secrets are not hardcoded;
• secrets are not visible in frontend;
• secrets are not written to logs;
• key rotation process is understood;
• expired credentials are handled.

If credentials are incorrect, the integration may look like “the API does not work,” while the real issue is access setup.

---

6. Check OAuth, API keys, and authentication between systems

Authentication should be checked in the context of the integration, not only as a separate endpoint.

Check that:

• source system can get a token;
• token contains required scopes;
• token is accepted by the target system;
• token expiration is handled;
• refresh token works;
• expired token is refreshed automatically if expected;
• invalid credentials return a clear error;
• revoked credentials are handled;
• auth failure is logged;
• auth failure is not lost silently;
• source system does not repeat auth request endlessly;
• support can understand auth failure from logs.

The main question is: can System A perform the required actions in System B with proper authorization?

---

7. Check scopes, permissions, and access rights

Sometimes authentication works, but permissions are insufficient.

Check that:

• integration user has required scopes;
• integration user has required role;
• integration user can read required records;
• integration user can create required records;
• integration user can update required statuses;
• integration user does not have excessive permissions;
• target system does not return unnecessary private data;
• forbidden action is handled clearly;
• permission error is logged;
• permission error does not become a generic failure;
• scope changes are documented.

For example, a CRM integration may authenticate successfully but lack permission to create leads or update owner.

---

8. Prepare test data in both systems

Integration testing requires data not only in the source system, but also in the target system.

Prepare:

• test user;
• test account;
• test customer;
• test product;
• test order;
• test lead;
• test payment;
• test subscription;
• test status;
• test workspace or organization;
• existing record in target system;
• missing record scenario;
• duplicate record scenario;
• invalid data scenario;
• edge case data;
• cleanup strategy.

Good test data makes it possible to test create, update, duplicate handling, status sync, and reconciliation.

---

9. Check data mapping

Data mapping is the heart of API integration testing.

Check that:

• source field goes to the correct target field;
• required fields are mapped;
• optional fields are mapped;
• unmapped fields are intentionally omitted;
• nested fields are mapped correctly;
• arrays are mapped correctly;
• IDs are mapped correctly;
• names are mapped correctly;
• emails are mapped correctly;
• phone numbers are mapped correctly;
• addresses are mapped correctly;
• amounts are mapped correctly;
• statuses are mapped correctly;
• enum values are mapped correctly;
• custom fields are mapped correctly.

For example, customer.email in e-commerce should become the correct email field in CRM, not an internal note or billing email without reason.

---

10. Check required, optional, and nullable fields

Different systems often understand field requirements differently.

Check that:

• source sends all required target fields;
• missing required field is handled;
• optional field can be omitted;
• nullable field is handled;
• empty string vs null is handled;
• default value is applied correctly;
• target validation errors are handled;
• source system stores validation failure;
• user-facing error appears if needed;
• failed integration does not create partial broken record;
• retry after fixing data works.

Useful question: what happens if System A does not have a field that System B considers required?

---

11. Check data formats

Data formats often break integration even when the fields are correct.

Check that:

• dates are formatted correctly;
• datetime includes timezone if needed;
• timezone conversion is correct;
• currency code is correct;
• decimal precision is correct;
• amount in major/minor units is correct;
• phone format is accepted;
• country code is accepted;
• address format is accepted;
• enum values are accepted;
• boolean values are accepted;
• IDs are accepted;
• arrays are accepted;
• special characters are accepted;
• Unicode characters are accepted.

For example, payment amount may be passed as 10.00, 1000 cents, or integer minor units. This should be explicitly tested.

---

12. Check record creation in target system

The first basic integration scenario is creating a record in the target system.

Check that:

• source action triggers API call;
• target system receives request;
• target system creates record;
• created record has correct fields;
• external ID is returned;
• source system saves external ID;
• created record is visible in target UI/API;
• created record is linked to correct account/customer;
• no duplicate record is created;
• created status is correct;
• timestamps are correct;
• logs show successful creation.

Example: lead from contact form should appear in CRM with correct name, email, company, source, UTM, and assigned owner.

---

13. Check record update

Integration often updates records, not only creates them.

Check that:

• source update triggers API call;
• target record is found by correct external ID;
• correct fields are updated;
• unrelated fields are not overwritten;
• partial update works;
• old value is replaced only where expected;
• update status is correct;
• target system shows updated data;
• source system stores update result;
• missing target record is handled;
• update failure is logged;
• retry works.

Important: update should not accidentally create a duplicate record if the target record already exists.

---

14. Check status mapping

Status synchronization is a common integration bug source.

Check mapping between:

• order statuses;
• payment statuses;
• subscription statuses;
• shipment statuses;
• lead statuses;
• ticket statuses;
• booking statuses;
• user statuses.

Check that:

• source status maps to correct target status;
• target status maps back correctly if two-way sync exists;
• unknown status is handled;
• deprecated status is handled;
• pending status is not treated as successful;
• failed status is not treated as completed;
• canceled status is handled;
• partial status is handled if supported;
• status history is preserved if needed.

For example, authorized, captured, paid, pending, failed, and refunded are different payment states. They should not all map into one generic “success.”

---

15. Check ID mapping and external references

Integration should store the relationship between internal and external records.

Check that:

• internal ID is saved;
• external ID is saved;
• correlation ID is saved;
• idempotency key is saved if used;
• target record reference is stored;
• source record reference is stored in target if needed;
• duplicate external ID is rejected;
• missing external ID is handled;
• old mapping does not point to the wrong record;
• IDs are searchable in logs/admin;
• support can find record by internal or external ID.

Without ID mapping, debugging, retry, reconciliation, and support become very difficult.

---

16. Check create vs update vs upsert behavior

Integration should know when to create a new record and when to update an existing one.

Check that:

• new source record creates target record;
• existing source record updates target record;
• upsert behavior is documented;
• duplicate key logic works;
• matching by email works if expected;
• matching by external ID works if expected;
• matching by order number works if expected;
• wrong match does not update another customer;
• duplicate prevention works;
• conflict is handled clearly.

Upsert bugs are especially dangerous: the system may update the wrong record instead of creating a new one.

---

17. Check duplicate prevention and idempotency

Retries, webhooks, and repeated requests often create duplicates.

Check that:

• same event is processed once;
• duplicate API request does not create duplicate record;
• retry after timeout is safe;
• duplicate webhook is safe;
• repeated callback is safe;
• same idempotency key returns expected result;
• duplicate order is not created;
• duplicate payment is not created;
• duplicate lead is not created if product rules require merge;
• duplicate email is not sent;
• duplicate fulfillment is not started;
• duplicate is logged or ignored clearly.

The main question is: what happens if the same event arrives twice?

---

18. Check retry behavior

Retry logic should help recovery, not create new problems.

Check that:

• retry happens after temporary failure;
• retry does not happen for non-retryable error;
• retry count is limited;
• retry interval is reasonable;
• exponential backoff is used if expected;
• retry preserves same payload;
• retry preserves idempotency key if needed;
• retry result is stored;
• failed retry is visible in logs/admin;
• user/team can trigger manual retry if supported;
• retry does not create duplicate record.

Retry is especially important for payments, orders, CRM lead creation, webhooks, fulfillment, and exports.

---

19. Check timeout behavior

Timeout can mean “operation failed” or “operation may still be processing.” It should be handled carefully.

Check that:

• source system handles target timeout;
• timeout is logged;
• timeout does not mark operation as successful without proof;
• timeout does not immediately create duplicate retry;
• user sees correct state if user-facing;
• pending state is used if needed;
• later confirmation can update state;
• reconciliation can detect final result;
• support can see timeout reason;
• timeout duration is reasonable.

Dangerous scenario: System A does not receive response from System B, sends request again, and creates a duplicate.

---

20. Check external API errors

Target system may return an error. Source system should handle it predictably. For deeper coverage of error schemas, safe messages, request IDs, and retryable vs non-retryable failures, use the API Error Handling Testing Checklist.

Check handling for:

• 400 validation error;
• 401 authentication error;
• 403 permission error;
• 404 not found;
• 409 conflict;
• 429 rate limit;
• 500 external server error;
• timeout;
• malformed response;
• empty response;
• maintenance mode.

Check that:

• error is logged;
• error is visible to support/team;
• user-facing message is clear if needed;
• operation is not marked as success;
• retry rules are correct;
• no duplicate side effect occurs;
• failed payload can be inspected safely.

---

21. Check rate limits

Rate limits can break the workflow under real load.

Check that:

• normal workflow does not hit rate limit;
• bulk sync behavior is safe;
• 429 is handled;
• Retry-After is respected if provided;
• backoff works;
• queue slows down instead of failing all records;
• user/team sees delayed sync status if needed;
• rate limit errors are logged;
• no duplicate records appear after retry;
• high-priority events are handled if priority exists.

Rate limit testing is especially important for CRM, analytics, product sync, order sync, bulk imports, and partner APIs.

---

22. Check queue and async processing

Many integrations work through queues or background jobs.

Check that:

• integration job is created;
• job payload is correct;
• job is processed;
• job status is visible;
• failed job is retried;
• failed job is not lost;
• dead-letter queue is configured if used;
• queue backlog is visible;
• job ordering is acceptable;
• duplicate job is safe;
• canceled event cancels scheduled job if needed;
• async delay is communicated if user-facing.

If integration is async, UI success does not mean the target system has already received the data.

---

23. Check webhooks

If target system sends a webhook back, it should be tested separately.

Check that:

• webhook URL is configured;
• webhook event is sent;
• webhook is received;
• signature verification works if used;
• payload schema is correct;
• event ID is present;
• related record is found;
• status is updated;
• duplicate webhook is ignored or handled;
• out-of-order webhook is handled;
• invalid signature is rejected;
• webhook failure is logged;
• retry from provider works;
• webhook does not create duplicate side effect.

Webhook testing is a key part of API integration testing, especially for payment, subscription, shipping, CRM, and identity flows.

---

24. Check callbacks and return URLs

Some integrations use user-facing redirects or callbacks.

Check that:

• callback URL is correct;
• return URL is correct;
• success callback is handled;
• failure callback is handled;
• canceled callback is handled;
• callback includes required reference;
• missing reference is handled;
• callback from wrong environment is rejected;
• repeated callback is safe;
• user lands on correct page;
• backend state is updated independently from UI when needed.

For example, a payment provider may return the user to a success page, but final payment status should be confirmed by backend event, not only by redirect.

---

25. Check two-way synchronization

If data flows in both directions, testing should cover both directions.

Check that:

• source → target sync works;
• target → source sync works;
• update from source is reflected in target;
• update from target is reflected in source;
• conflict rules are documented;
• latest update wins only if expected;
• protected fields are not overwritten;
• status mapping works both ways;
• deletion/cancellation sync works;
• sync loop does not occur;
• audit trail is available.

Two-way sync is easy to break because of conflicts, loops, and unclear source of truth.

---

26. Check data reconciliation

Even if the integration works, there should be a way to verify that data matches.

Check that:

• internal records match external records;
• counts match;
• totals match;
• statuses match;
• failed records are listed;
• missing records are detected;
• duplicate records are detected;
• reconciliation report is available if needed;
• manual reconciliation is possible;
• support can compare by order ID, customer ID, external ID, or timestamp.

Reconciliation is especially important for payments, orders, invoices, subscriptions, fulfillment, accounting, and finance flows.

---

27. Check consistency after partial failure

Partial failure is a common and difficult integration problem.

Examples:

• order created internally, but not sent to ERP;
• payment succeeded, but order status was not updated;
• lead created in CRM, but notification failed;
• shipment created, but tracking was not saved;
• subscription activated, but email failed.

Check that:

• partial failure is detected;
• state is not marked fully complete;
• retry is possible;
• support can see failure;
• user sees appropriate state if needed;
• duplicate record is not created after recovery;
• reconciliation catches mismatch;
• operations has alert for critical partial failure.

Partial failure should be a managed state, not a hidden breakage.

---

28. Check data transformation

Integration often transforms data before sending it.

Check that:

• names are transformed correctly;
• address is normalized correctly;
• country codes are converted correctly;
• currency is converted correctly;
• amount units are converted correctly;
• enum values are converted correctly;
• internal status is mapped correctly;
• product SKU is mapped correctly;
• phone is normalized correctly;
• date/time is converted correctly;
• unsupported characters are handled;
• truncation rules are safe.

For example, if the target system accepts country as US and the source stores United States, mapping should be explicit.

---

29. Check business rules between systems

Business rules should match across systems or be explicitly mapped.

Check that:

• target system accepts source business rules;
• required approvals are respected;
• tax/shipping rules are consistent;
• subscription rules are consistent;
• inventory rules are consistent;
• cancellation rules are consistent;
• refund rules are consistent;
• user status rules are consistent;
• region restrictions are respected;
• plan limits are respected;
• custom business rules are documented.

Integration breaks not only because of technical mismatch, but also because of different business assumptions.

---

30. Check order/payment integration

If integration is related to orders or payments, check that:

• order is sent to payment/ERP system;
• amount is correct;
• currency is correct;
• customer reference is correct;
• payment reference is saved;
• payment status is returned;
• webhook updates status;
• failed payment is handled;
• pending payment is handled;
• refund status is synced if in scope;
• duplicate payment does not create duplicate order;
• order total matches payment amount;
• reconciliation is possible.

Payments require especially careful checks for idempotency, statuses, retries, and webhooks.

---

31. Check CRM integration

For CRM integration, check that:

• lead/contact is created;
• name, email, and company are mapped correctly;
• phone is mapped;
• source is mapped;
• campaign/UTM is mapped;
• owner is assigned correctly;
• lifecycle stage/status is correct;
• duplicate lead logic works;
• existing contact is updated if expected;
• notes or activities are created if expected;
• failed CRM request is logged;
• sales team can find the record.

CRM integration often breaks not because request failed, but because the lead went to the wrong owner or lacked source/campaign data.

---

32. Check ERP/accounting integration

For ERP or accounting integration, check that:

• order/invoice is created;
• customer is mapped;
• tax is mapped;
• totals are mapped;
• product SKU is mapped;
• accounting codes are correct;
• currency is correct;
• invoice status is correct;
• payment status is correct;
• refunds/credits sync if in scope;
• duplicate invoice is not created;
• failed sync is visible to finance/ops;
• reconciliation report is available.

ERP/accounting bugs often have financial impact, so data accuracy matters more than simply “record created.”

---

33. Check fulfillment/shipping integration

For warehouse, fulfillment, or shipping provider, check that:

• fulfillment request is created;
• correct items are sent;
• variants/SKUs are correct;
• quantity is correct;
• shipping address is correct;
• shipping method is correct;
• carrier/service is mapped;
• tracking number is returned;
• shipment status is synced;
• canceled order is not fulfilled;
• duplicate fulfillment is not created;
• invalid address is handled;
• failed fulfillment is visible to operations.

Shipping integration errors directly affect customer experience and operational cost.

---

34. Check identity/SSO integration

For identity provider, SSO, or user sync, check that:

• user is created;
• user attributes are mapped;
• email is mapped;
• name is mapped;
• organization/workspace is mapped;
• roles/groups are mapped;
• login works;
• deprovisioned user loses access;
• disabled user is handled;
• token/scopes are correct;
• session behavior is correct;
• callback works;
• permissions are not over-granted.

Identity integration bugs can be security-critical.

---

35. Check email/notification provider integration

Check that:

• provider receives send request;
• recipient is correct;
• template ID is correct;
• dynamic variables are correct;
• language/locale is correct;
• send status is returned;
• bounce/failure is handled;
• duplicate email is not sent;
• unsubscribe/preferences are respected if applicable;
• logs allow tracing message;
• sandbox/prod sender is correct.

Email integration testing should check not only “email arrived,” but also payload, template, variables, delivery status, and duplicate prevention.

---

36. Check analytics integration

For analytics integration, check that:

• event is sent;
• event name is correct;
• user ID/anonymous ID is correct;
• properties are mapped;
• value/currency is correct;
• product IDs are correct;
• source/UTM is preserved;
• event is not duplicated;
• failed event is handled if critical;
• environment is separated;
• test traffic is marked or excluded;
• privacy rules are respected.

Analytics integration bugs may not break UI, but they break decision-making.

---

37. Check logging

Logs should help understand where the integration failed.

Check that logs contain:

• source system event;
• target system request;
• response status;
• error reason;
• internal ID;
• external ID;
• correlation ID;
• idempotency key if used;
• timestamp;
• retry count;
• environment;
• integration name;
• no sensitive secrets;
• no full payment data;
• enough context for debugging.

“Integration failed” without IDs, payload reference, and external response is almost useless.

---

38. Check monitoring and alerts

Critical integrations should be visible in monitoring.

Check that:

• success rate is monitored;
• failure rate is monitored;
• latency is monitored;
• queue backlog is monitored;
• webhook failures are monitored;
• retry failures are monitored;
• rate limit errors are monitored;
• auth errors are monitored;
• alert threshold is defined;
• alert is sent to the correct team;
• dashboard exists if needed;
• production incident can be detected quickly.

Without monitoring, integration may be broken for hours or days before a user or client reports the problem.

---

39. Check support and admin visibility

Support or operations team should understand what happened.

Check that:

• integration status is visible in admin;
• external ID is visible;
• sync status is visible;
• last sync time is visible;
• failure reason is visible;
• manual retry is available if supported;
• retry permission is restricted;
• record can be searched by internal/external ID;
• support can explain status to user;
• failed records list is available;
• no sensitive data is exposed to wrong roles.

If business depends on integration, visibility should exist outside backend logs.

---

40. Check manual retry and recovery

Critical integrations need a recovery path.

Check that:

• failed integration can be retried;
• retry uses the same safe payload or updated payload according to rules;
• retry does not create duplicate;
• manual retry is logged;
• retry permissions are restricted;
• user/team sees retry result;
• permanent failure is marked clearly;
• recovery after credential fix works;
• recovery after target system downtime works;
• operations can resolve common failures.

Manual retry is especially important for orders, invoices, fulfillment, payments, CRM leads, and imports.

---

41. Check security between systems

API integration testing should include security at the boundary between systems.

Check that:

• HTTPS is used;
• credentials are stored securely;
• credentials are not exposed in client;
• API keys have least privilege;
• webhook signatures are verified;
• callbacks are validated;
• incoming payload is not trusted blindly;
• access to external data is restricted;
• private data is not sent unnecessarily;
• logs do not expose secrets;
• target system does not receive extra sensitive fields;
• integration user is not over-permissioned.

Integrations often become a weak security point because systems trust each other too broadly.

---

42. Check privacy and data minimization

Integration should not send unnecessary personal data.

Check that:

• only required personal data is sent;
• sensitive fields are excluded if not needed;
• consent status is sent if required;
• marketing consent is respected;
• data retention expectations are known;
• delete/anonymize flow is supported if in scope;
• data subject request impact is understood;
• test data is safe;
• production data is not sent to sandbox;
• external provider data handling is understood.

QA does not replace legal review, but it can catch obvious mistakes, such as sending a full address to a system that only needs email.

---

43. Check version compatibility

If one system is updated, integration should not break unexpectedly.

Check that:

• target API version is known;
• source uses supported version;
• deprecated endpoint is not used;
• schema changes are handled;
• new optional fields do not break parser;
• removed fields are handled;
• enum expansion is handled;
• partner API changelog was reviewed;
• SDK version is compatible;
• fallback plan exists if provider changes behavior.

Version mismatch often breaks integrations after provider upgrades or internal backend refactoring.

---

44. Check sandbox vs production behavior

Sandbox and production can differ.

Check that:

• sandbox behavior is documented;
• production behavior is documented;
• test credentials are not used in production;
• production credentials are not used in sandbox;
• test payments do not create real charges;
• test emails do not go to real customers;
• sandbox webhooks are configured separately;
• production webhooks are configured separately;
• domain differences are handled;
• test records are clearly marked;
• production smoke is safe.

Before release, confirm that production configuration is actually ready, not only that the integration works in sandbox.

---

45. Check migration or provider switch

If the team changes provider or migrates integration, additional checks are needed.

Check that:

• old provider is disabled according to plan;
• new provider is enabled;
• duplicate sending is not happening;
• historical IDs are migrated or mapped;
• old webhooks are disabled;
• new webhooks are configured;
• retry queues are cleared or migrated;
• fallback plan exists;
• data reconciliation is completed;
• support knows about provider switch;
• monitoring is updated;
• no records are lost during cutover.

Provider migration is a high-risk integration scenario, especially for payments, emails, CRM, and fulfillment.

---

46. Check bulk sync and batch jobs

If integration works in batches, check that:

• batch starts;
• batch processes all eligible records;
• skipped records are logged;
• failed records are logged;
• partial success is handled;
• failed records can be retried;
• batch does not create duplicates;
• batch respects rate limits;
• batch can resume after interruption;
• progress is visible;
• summary report is generated;
• large batch performance is acceptable.

Bulk sync bugs often appear only with realistic data volume.

---

47. Check performance and latency of the integration workflow

Integration performance is not only endpoint speed. It is the time of the entire process.

Check that:

• source action does not hang;
• target system response time is acceptable;
• async processing delay is acceptable;
• webhook delay is acceptable;
• retry delay is acceptable;
• queue latency is acceptable;
• user-facing state is clear during processing;
• slow target system does not block UI too long;
• monitoring shows latency;
• SLA/SLO is understood if applicable.

For business users, it matters not only that “the record arrived,” but also that it arrived fast enough for the process.

---

48. Check data consistency after end-to-end workflow

After the full workflow, compare systems.

Check that:

• source record exists;
• target record exists;
• internal ID is mapped;
• external ID is mapped;
• important fields match;
• statuses match;
• amounts match;
• dates match;
• owner/assignee matches;
• audit history is acceptable;
• no duplicate records exist;
• no downstream event is missing;
• final state matches business expectation.

This is the key check of API integration testing: the result should be consistent across systems.

---

49. Run production integration smoke after release

After integration release, run a short production smoke test.

Check that:

• production credentials work;
• production URLs are correct;
• safe test event triggers integration;
• target system receives record;
• field mapping is correct;
• webhook/callback returns;
• status updates;
• no duplicate record is created;
• logs are clean;
• monitoring is stable;
• rate limit is not triggered;
• support can find the record;
• there is no staging data;
• no test customer is exposed;
• rollback/fallback plan is not needed.

Production integration smoke should be short, safe, and agreed in advance.

---

50. Document integration testing result

After testing, document the result.

Record:

• integration name;
• source system;
• target system;
• environment;
• test data;
• tested workflow;
• created/updated record IDs;
• external IDs;
• webhook event IDs;
• logs/correlation IDs;
• found issues;
• remaining risks;
• pass/fail decision;
• owner;
• next steps.

An integration bug without IDs, timestamps, and environment is almost impossible to debug quickly.

---

Common mistakes

1. Treating API integration testing as normal API testing

An endpoint can work correctly while the business process between systems is broken.

2. Checking only successful request/response

Integration testing must include retries, timeouts, external errors, webhooks, duplicates, and reconciliation.

3. Not testing data mapping

Most integration bugs are field mapping bugs: wrong status, wrong amount, wrong owner, wrong customer, wrong external ID.

4. Mixing sandbox and production configuration

Wrong base URL, webhook URL, API key, or environment variable can send data to the wrong system.

5. Not testing duplicates

Retries, callbacks, and webhooks can create duplicate orders, leads, payments, invoices, emails, or fulfillment requests.

6. Ignoring rate limits

Integration may work with one record and fail during real traffic, bulk sync, or retries.

7. Not checking external API errors

The target system will fail sometimes. Source system must handle that without silent data loss.

8. Not reconciling data between systems

“Request succeeded” is not enough. Records and statuses must match in both systems.

9. Not checking logs and support visibility

If support cannot find where integration failed, every incident becomes engineering work.

10. Not running production integration smoke

Sandbox success does not guarantee production success. Production credentials, URLs, webhooks, permissions, and data behavior can differ.

---

FAQ

What is an API Integration Testing Checklist?

An API Integration Testing Checklist is a list of checks for verifying data exchange between two or more systems through APIs.

It helps make sure that the source system sends correct data, the target system receives and processes it correctly, fields are mapped, statuses are synchronized, webhooks are delivered, retries are safe, errors are handled, duplicates are prevented, logs are useful, and data is consistent across systems.

How is API integration testing different from API testing?

API testing checks an endpoint: status codes, validation, authentication, authorization, request/response schema, and endpoint behavior.

API integration testing checks the business workflow between systems: for example, an e-commerce order appeared in ERP, payment status came back through webhook, CRM lead received the correct owner, and retry did not create a duplicate.

What should be checked in API integration testing?

At minimum, check:

• source and target systems;
• business workflow;
• authentication/API keys/OAuth;
• permissions/scopes;
• environment URLs;
• data mapping;
• required fields;
• IDs and external references;
• status mapping;
• retries;
• timeouts;
• webhooks/callbacks;
• rate limits;
• external API errors;
• logs;
• monitoring;
• data reconciliation.

How do you test data mapping between systems?

Create or update a record in the source system and check the target system.

Verify fields such as:

• names;
• emails;
• phone;
• address;
• IDs;
• status;
• amount;
• currency;
• date/time;
• SKU;
• owner/assignee;
• custom fields.

Expected result: important fields in the target system match source data or documented mapping rules.

How do you test webhook integration?

Check that:

• webhook URL is configured;
• event is sent;
• event is received;
• signature is verified;
• payload is correct;
• related record is found;
• status is updated;
• duplicate webhook is safe;
• invalid webhook is rejected;
• webhook failure is logged;
• retry works.

How do you test retry behavior in API integration?

Simulate a temporary failure or timeout.

Expected result:

• retry happens only when appropriate;
• retry uses safe payload;
• idempotency is preserved if needed;
• duplicate record is not created;
• failure is visible in logs/admin;
• final result can be reconciled.

How do you test duplicate prevention?

Check repeated API request, retry after timeout, duplicate webhook, repeated callback, and multiple tabs/jobs if relevant.

Expected result: system processes the event once or safely ignores duplicates according to product rules.

How do you test external API errors?

Simulate or trigger:

• validation error;
• authentication error;
• permission error;
• rate limit;
• timeout;
• server error;
• malformed response.

Expected result: source system logs the error, does not mark operation as successful, does not lose data, and provides retry or recovery path if needed.

How do you know API integration works?

API integration can be considered working if:

• source system sends correct data;
• target system receives and stores correct data;
• required fields are mapped;
• statuses are synchronized;
• external IDs are stored;
• webhooks/callbacks work;
• retries do not create duplicates;
• rate limits are handled;
• errors are visible and recoverable;
• logs and monitoring are useful;
• data matches in both systems;
• production integration smoke passed.

Should API integration testing be automated?

Partly, yes.

Good candidates for automation:

• create record in target system;
• update sync;
• status sync;
• webhook processing;
• duplicate event handling;
• mapping checks;
• retry-safe scenarios;
• production synthetic smoke checks.

Manual testing still matters for provider setup, sandbox/prod config, admin visibility, support workflow, reconciliation, and incident recovery.