An API can return HTTP 200 and still produce a broken business process.
A customer may be created with the wrong currency. Page one of a paginated endpoint may load while pages two through fifty are silently ignored. A retry may create the same invoice twice. An expired OAuth token may stop a nightly synchronization. A vendor may add a new status that your mapping sends to “Unknown.” A webhook can arrive twice, out of order, or several hours late.
That is why API integration testing must validate more than connectivity.
The real objective is to prove that information moves correctly, securely and recoverably between systems under both normal and abnormal conditions.
Actiknow’s custom web application development practice includes API integration, testing, deployment and ongoing support. Those stages belong together because an integration is not finished when the first successful request appears in a development console.
Start With the Business Contract
Before writing tests, define what the integration is supposed to accomplish.
A technical specification may say POST /customers. The business contract should say what event creates a customer, which system owns each field, which records are eligible, how duplicates are identified, how quickly the destination should update and what happens when the destination rejects the request.
For every important flow, document:
- trigger;
- source;
- destination;
- field mapping;
- required fields;
- authoritative system;
- expected latency;
- duplicate rule;
- delete or cancellation behavior;
- error owner;
- recovery behavior.
Testing then proves this contract.
Actiknow’s requirements guidance emphasizes connecting business needs to application capabilities, technical design and acceptance criteria. Integration tests should follow the same chain.
Test Authentication Separately
Authentication failures deserve explicit tests because they are operationally common.
Validate valid credentials, expired credentials, revoked credentials, insufficient scopes, invalid tokens and token refresh.
For OAuth integrations, test what happens when an access token expires during a long-running process. Confirm refresh behavior and verify that refreshed credentials are stored securely.
Do not log secrets or tokens during failed tests.
Actiknow’s security practices describe encrypted connections, OAuth where possible and minimum necessary permissions. API tests should confirm those controls are implemented rather than merely documented.
Test Field Mappings With Known Records
Field mapping errors are among the easiest defects to miss because both systems may accept the data.
Create fixtures with known values and verify every material field after transfer.
Test:
- strings;
- numbers;
- dates;
- timezones;
- booleans;
- enums;
- nulls;
- special characters;
- large values;
- leading zeros;
- identifiers;
- currency;
- nested structures.
Pay special attention to values that look interchangeable but are not. An account ID is not necessarily a customer ID. A created date is not necessarily an effective date. A local timestamp is not UTC.
For transformations, test both input and expected output.
Test Required and Optional Fields
APIs often behave differently when optional fields are absent, null or empty.
Build cases for:
- field omitted;
- field present as null;
- empty string;
- zero;
- false;
- empty array.
Confirm the integration does not convert these states accidentally.
If a destination requires a field the source does not guarantee, define the business rule: reject, default, enrich or route to an exception queue.
Test Pagination
A connector that only reads the first page can pass a small development test.
Use enough test data to force multiple pages.
Validate:
- page-number pagination;
- offset/limit;
- cursor pagination;
- next-link behavior;
- changing page sizes;
- last-page behavior;
- empty pages;
- pagination tokens that expire.
Count source and destination records after extraction.
Actiknow’s Fivetran-versus-custom-pipeline guide lists pagination, incremental cursors, retries, idempotency and partial failures among the production concerns a custom connector must handle. Testing should cover those exact operational boundaries.
Test Incremental Synchronization
Many integrations do not reload everything.
They use updated timestamps, sequence numbers, cursors or event streams.
Test records updated exactly at the boundary. Test multiple records with the same timestamp. Test late-arriving records. Test clock differences. Test an interrupted run that resumes from the last checkpoint.
The safest design usually includes an overlap or another mechanism that prevents boundary records from disappearing, combined with deduplication downstream.
Test Create, Update and Delete Behavior
Do not test only creates.
Verify how an existing record is matched. Test changed values, unchanged values, missing records, soft deletes, hard deletes, cancellations and reactivations.
Decide whether the destination mirrors current state or preserves history.
A deletion event is particularly important. Many integrations happily add data forever while never removing records that no longer exist upstream.
Test Idempotency and Duplicate Events
Assume requests will be retried.
Send the same event twice.
Then send it five times.
Confirm the destination contains one logical outcome where that is the intended behavior.
Use stable source identifiers or idempotency keys. If the destination cannot enforce idempotency, test the integration’s deduplication mechanism.
Duplicate handling is not an edge case in distributed systems. It is normal failure recovery.
Test Retries
Force temporary failures.
Return 500 errors. Simulate 429 rate-limit responses. Create network timeouts. Interrupt a connection after the destination may have processed the request.
Verify:
- which errors retry;
- which errors fail immediately;
- retry delay;
- exponential backoff;
- maximum attempts;
- idempotency;
- final failure handling;
- alerting.
A retry policy should distinguish transient failures from permanent validation errors. Repeating a malformed request twenty times only creates noise.
Test Rate Limits
Vendor APIs often enforce quotas.
Simulate or exercise the documented rate limit.
Confirm the integration respects Retry-After headers where applicable, reduces request rate and resumes without losing records.
Also test the aggregate architecture. Three separate jobs may each stay below a limit while collectively exceeding the vendor’s quota.
Central monitoring should make rate-limit pressure visible.
Test Webhooks
Webhook integrations have their own failure modes.
Validate signature verification if provided by the vendor.
Test duplicate delivery, delayed delivery, out-of-order delivery, malformed payloads, unknown event types and replay.
Return the appropriate acknowledgement quickly if the provider expects it, and move expensive processing to an asynchronous worker where appropriate.
Do not assume delivery order unless the provider guarantees it.
Test Schema Changes
APIs evolve.
Create tests for additional fields, missing fields, changed types and new enum values.
The integration should not silently corrupt data when a vendor adds a value your code does not recognize.
Decide which changes should fail fast and which should be tolerated.
For analytical pipelines, unexpected schema changes should be observable even when ingestion continues.
Actiknow’s production-readiness guide notes that production systems must handle field type changes, duplicates, rate limits, credential expiry and partial data. Schema tests turn those concerns into repeatable checks.
Test Partial Failure
Batch integrations are particularly vulnerable to partial success.
Suppose 1,000 records are sent and 17 fail validation.
Does the system retry all 1,000, creating duplicates? Does it lose the 17? Does it mark the batch successful because most records worked?
Test mixed batches deliberately.
The integration should preserve enough context to retry failed records without corrupting successful ones.
Reconcile the expected and actual record counts after the run.
Test Vendor Edge Cases
Read the vendor documentation and support history for unusual behavior.
Examples include:
- eventual consistency;
- delayed search indexing;
- different limits by endpoint;
- deleted objects disappearing from list endpoints;
- API fields not matching the user interface;
- timezone defaults;
- sandbox behavior differing from production;
- webhooks unavailable for some object types.
Build tests around the behavior that can materially affect your process.
Do not assume a generic REST client test is sufficient.
Test Security Boundaries
Integration testing should verify authorization, not only authentication.
Can the service identity read more data than required?
Can it write to endpoints it should never modify?
Are tenant identifiers validated?
Can one customer’s request retrieve another customer’s record?
Are secrets excluded from logs?
Are sensitive payloads encrypted in transit?
Actiknow’s BI security guide recommends documenting each data hop, authentication method, encryption, credential protection and ownership. The same discipline applies to operational APIs.
Test Performance and Volume
A flow that processes ten records correctly may collapse at 100,000.
Use representative payload sizes and volumes.
Measure throughput, memory, API consumption, queue depth and end-to-end latency.
Test bursts as well as averages.
If the integration has a service-level objective, prove it under expected peak conditions.
Build Reconciliation Tests
Technical tests answer whether requests succeeded.
Reconciliation answers whether the business data arrived completely.
Compare:
- eligible source records;
- processed records;
- successful destination records;
- rejected records;
- duplicates;
- late records;
- totals of important amounts.
For financial or high-value operational integrations, reconciliation should be a production control, not only a pre-launch test.
Separate Contract Tests From End-to-End Tests
Contract tests verify that your implementation matches the API contract and expected payload structures.
End-to-end tests verify the real business process across systems.
You need both.
Contract tests are faster and easier to automate.
End-to-end tests reveal configuration, credential, workflow and cross-system problems that mocks cannot reproduce.
Use Sandboxes Carefully
Vendor sandboxes are useful but imperfect.
They may contain different data volumes, features, permissions or rate limits from production.
Document known differences.
Where safe, perform controlled production smoke tests after deployment using identifiable test records.
Do not assume a sandbox pass proves production behavior.
Automate the Stable Tests
Automate repeatable checks:
- authentication;
- mapping fixtures;
- schema contracts;
- pagination;
- idempotency;
- retry policies;
- known validation cases;
- reconciliation samples.
Keep exploratory testing for vendor-specific behavior and new failure modes.
Run critical integration tests in CI/CD where practical.
Actiknow’s application-development guidance describes layered testing across unit, integration, end-to-end and performance testing. API integrations should use the same layered approach.
Create a Production Test Matrix
For each integration, maintain a concise matrix:
- happy path;
- authentication failure;
- validation failure;
- duplicate event;
- pagination;
- rate limit;
- temporary server error;
- timeout;
- partial batch failure;
- schema change;
- delete;
- late record;
- recovery;
- security boundary;
- volume test.
Mark which tests are automated and which require periodic manual execution.
This gives the team a repeatable release gate.
Test Monitoring and Alerts
Monitoring itself must be tested.
Cause a controlled failure and confirm the right person receives an actionable alert.
An alert should identify the integration, environment, failure class, affected window and where to investigate.
Avoid alerts that simply say “Job failed” without context.
Test Recovery, Not Just Failure
The most important question after an error is: can the system return to a correct state?
Pause the integration. Create source changes. Resume it.
Confirm no records are lost and no duplicates are created.
Revoke credentials, restore them and replay the failed period.
Simulate a bad deployment and verify rollback.
Recovery tests are what distinguish resilient integrations from integrations that merely detect errors.
Define Release Acceptance
Before production, require evidence that:
- business mappings are approved;
- authentication and least privilege are verified;
- pagination is complete;
- incremental boundaries are safe;
- retries are idempotent;
- rate limits are handled;
- duplicates are controlled;
- deletes have defined behavior;
- partial failures are recoverable;
- reconciliation passes;
- monitoring works;
- support ownership is clear.
The exact rigor should follow business risk.
Frequently Asked Questions
What is API integration testing?
It is testing the behavior of data and workflows across connected systems, including mappings, authentication, errors, retries, pagination, security and recovery.
Is a successful API response enough?
No. The response can succeed while the wrong data is written, records are omitted or duplicates are created.
How do you test pagination?
Use enough records to require several pages, validate every page is requested and reconcile the complete source count with processed results.
Why test duplicate events?
Webhooks and retried requests can be delivered more than once. The integration should avoid unintended duplicate business outcomes.
How should rate limits be tested?
Exercise documented quota behavior, verify backoff and retry handling, and confirm records are not lost when processing resumes.
Should API tests run automatically?
Stable contract, mapping, pagination, retry and idempotency tests are strong automation candidates. Keep end-to-end and vendor-specific testing as well.
What is the most important production control?
For critical data flows, reconciliation is essential because it proves business completeness rather than merely technical execution.
Conclusion
API integration testing should assume that networks fail, credentials expire, vendors change behavior, events repeat and data contains unexpected values.
Test the business contract, not only the endpoint. Force failures. Reconcile records. Verify security. Prove recovery.
If your integrations have become critical to operations, Actiknow can help design and test API workflows with production-grade error handling, monitoring and reconciliation. Discuss your API integration requirements with Actiknow.