Integration acceptance verifies that the intended business record reaches the receiving system correctly and can be reconciled after important failures. Test identifiers, field mappings, permissions, retries and changed statuses with controlled records. Assign monitoring and exception owners. A green connector status or successful API response does not by itself prove the downstream workflow is correct.
- Verify downstream record state rather than connection status alone.
- Exercise delayed, rejected and duplicate messages safely.
- Hand over reconciliation and exception handling to named owners.
Start from the approved boundary
Use the integration scope to list record ownership, shared fields, status mappings and expected timing. Confirm the versions and accounts under test. If the implemented connection differs from the design, resolve that change before acceptance; otherwise tests may prove a behavior nobody has agreed to operate.
Define the observable result for each scenario. An order handoff might require one downstream record with the same business reference and correct quantities. A contact sync might require specific fields while leaving others untouched. Those expectations make evidence more meaningful than a generic successful response message.
Prepare controlled test records
Use known identifiers and values that can be traced through both systems. Include a related record, an empty optional field and a meaningful boundary value. Keep unnecessary sensitive data out of screenshots and logs. Arrange authorized test environments and control any external effects such as messages or dispatch requests.
Record the expected upstream and downstream states before execution. Ensure test cleanup follows the platform’s supported procedure so subsequent runs are not confused by old records. Where integration tests cannot be isolated completely, obtain the necessary operational coordination and choose a safe bounded verification method.
Verify normal and changed records
Confirm initial creation, relevant updates and supported cancellation or closure. Inspect relationship identifiers and important fields, including units and dates. Check that a downstream edit behaves according to the agreed authority rule instead of being silently overwritten or synchronized back in an unexpected direction.
Test access with the actual integration account rather than an unrestricted developer account. An interface can work during development and fail after least-privilege permissions are applied. Conversely, successful tests with overly broad authority may hide an unnecessary exposure that should be resolved before routine operation.
Test an illustrative delayed response
Illustrative scenario: a fulfilment connector sends an order, the receiving application creates it, and acknowledgement is delayed. A controlled retry uses the same business reference. Acceptance checks that the downstream state contains the intended single order and that the originating team can determine whether the handoff completed.
A second scenario returns a validation error for an unknown item code. The operator follows the documented correction and resend path. These scenarios test ambiguity and recovery, without assuming every platform uses the same duplicate-prevention mechanism or offers the same retry controls.
Reconcile and inspect diagnostics
Compare source and destination counts, identifiers, status and relevant totals. Review missing or delayed records using the documented exception route. Technical logs can aid diagnosis, but they should not expose unnecessary sensitive values. An authorized operator must be able to understand the business issue without becoming an integration developer.
Measure expected timing under representative conditions and record any remaining uncertainty about volume or provider limits. A small test does not establish peak capacity. If a larger validation is needed, plan it safely and separately rather than sending uncontrolled load to a live customer-facing service.
Accept operating ownership
Ask the future owner to identify a failed handoff, perform an approved correction and reconcile the result using the handover material. Document support boundaries, credentials, rotation and maintenance responsibility. Acceptance includes a usable operating route, not just the developer’s ability to demonstrate a happy-path message.
Retain the scenario pack for changes to either connected system. EasyManageX listings are illustrative and do not establish working connectors. The deployed integration’s observed behavior, permissions and reconciliation evidence determine whether this handoff is ready for the agreed operating scope.
Your working checklist
- Confirm implemented record authority.
- Write expected downstream states.
- Use traceable controlled records.
- Test actual integration permissions.
- Exercise retry and rejection paths.
- Reconcile identifiers and totals.
- Demonstrate exception-owner handover.
Common questions
What is more useful than a connector status light?+
Evidence that the intended record exists downstream with correct fields, relationships and status, plus a way to reconcile it with the source. A status light may show connectivity while individual records fail validation or remain delayed. Test the business result and exception process directly.
Should failure tests run against production?+
Prefer approved isolated or staging environments with controlled records and side effects. Some final checks may require carefully coordinated production verification, but do not disrupt live service or send uncontrolled load. Choose a method with the responsible operators that safely establishes the required behavior.
Who accepts an integration after development?+
The accountable process owner confirms business outcomes, the technical owner confirms implementation and access, and the future operator verifies monitoring and recovery procedures. Use your organizational governance arrangements, ensuring acceptance is not limited to the developer demonstrating that a request returned a successful response.
Sources and further reading
These primary references explain relevant concepts. Our scenarios and working checklists are original, illustrative guidance.
- OWASP Authorization Cheat Sheet
Least privilege, deny by default and permission verification.
- OWASP Logging Cheat Sheet
Audit event design and sensitive data exclusions.
Published by EasyManageX as practical, AI-assisted guidance. Examples are illustrative. Confirm software capabilities, licence terms and project-specific requirements before committing. Read our editorial policy.
