CheckcraftIntegration testing across API, logs and database
Get help with your first test →
A request was accepted but the order never appeared downstream. Follow one operation across the integration boundary.
Define the boundary
The illustrative orders service accepts an orderId and a downstream service stores READY. Agree a correlation key and an acceptable propagation delay. This is a testing pattern, not a ready-made connector to a particular CRM or payment service.
Correlate the request and logs
Save the test request and assert its status and fields. Select logs for the same operation. Filtering only for ERROR may hide earlier evidence. Define expected events instead of accepting any matching log.
Verify the downstream state
With authorized database access, Pro can perform a SELECT verification after the API request. Allow an agreed persistence timeout for asynchronous work. A record that has not arrived yet differs from one that never arrives.
Adapt the assertion
An e-commerce check may target an order total, a logistics check a shipment status and an EdTech check access to a lesson. Each needs its own contract. Checking an API gateway endpoint does not audit the gateway. Checking an event-driven outcome does not imply a native message broker client.
Hand the workflow to support
Save the request, expected events, environment and report. Support can repeat that operation after a configuration change. One passing workflow does not certify the whole distributed system.
Start with the linked example and compare its result with your own test requirement.