Start a self-built API integration with one harmless read task, a test environment and synthetic records. Do not begin with production credentials or write-back. The first experiment should show exactly what is requested, which outcome is expected and how the flow stops on a discrepancy.
Use the English API test worksheet. It is a test specification, not a universal connector script or permission to use production.
Define one read-only task and minimal access
For example, retrieve three fictional open orders and display only their identifier and status. Specify source, filter and destination, then exclude real customers, financial actions, scheduled production work and create, update or delete operations.
Read-only is not automatically harmless if the permitted response contains sensitive data. Use a test identity restricted to the relevant source. Keep secrets out of the worksheet and source code; record only the controlled storage reference and the person who can revoke access.
Write expectations before executing
| Case | Transport expectation | Business expectation |
|---|---|---|
| Valid list | Successful response under the API contract | Correct count, unique IDs and required fields |
| Unknown record | Contract-defined not-found result | No unrelated or invented record |
| Missing authority | Contract-defined access failure | No protected data returned |
| Temporary failure | Identifiable failure | Not an empty list treated as success |
Check the actual contract. Status 200 alone does not prove complete or valid records, and different APIs can use different documented error representations.
Keep bounded diagnostic evidence
Record test reference or correlation ID, endpoint name, status, duration and error category. Exclude tokens, authorisation headers and unrestricted payloads. The owner must be able to tell which case failed and whether repeating it is safe.
Exercise failure cases and repeat the read
Test missing access, unknown records, invalid input, unavailable service and an attempted forbidden write. Do not replace a failure with a successful-looking empty result. Repeat the read task and check both duplicate rows and unintended side effects.
An illustrative synthetic test
A local test specification expects three open orders. Its intentionally defective case returns two, so two received plus one missing accounts for the three expected. That case should be a no-go, not accepted because the request itself completed.
The operator can also define missing-record, missing-token, invalid-route and prohibited-write outcomes from the chosen contract. The Dutch source illustrates 404, 401, 400 and 405 for these local cases; those are example expectations, not a claim that every external API uses that mapping.
No public endpoint, customer system or universal exercise code is provided by this article. Execute your actual implementation in your controlled development environment and preserve observations separately from this model.
Decide before expanding the scope
Proceed only when required records, values and expected failures behave correctly and logs and access have owners. A passing read experiment proves that version and dataset; it does not approve writing or production use. Recheck after a material contract change.
Choose the right implementation scope
For a maintained connection, see API integration. If the source lacks a suitable interface, assess API development as a different scope. If Excel receives the result, check spreadsheet integration limits before treating a successful import as a two-way process.