An interface for a program
Through an API, one program requests data or an action from another: reading a directory, creating a ticket or checking an order. Documentation defines the available operations, request parameters and responses. A caller does not need to know the service’s internal implementation.
Imagine a repair request
Imagine a fictional property-management company. A resident fills out a form, and the request should reach the field-service system with an address and photograph. Both products have APIs, which seems sufficient. Yet the receiving system creates only text records; uploading attachments is a separate operation.
Integration must now connect two steps and explain what happens if the first succeeds and the second fails. Otherwise dispatchers receive incomplete requests while residents see confident success messages. Judge integration by a complete record an executor can actually use.
The agreement includes data meaning
Matching field names do not guarantee matching contents. An address may be free text or a directory reference; a date may use local time or an explicit timezone; a status may represent a team's internal stage. Define transformations and cases where information cannot transfer correctly.
Take several ordinary records and a borderline one: an incomplete address, unknown category or large file. Specify expected outcomes beforehand. Compatibility becomes a test of preserved information, transformations and what operators see when transfer is impossible.
No response does not mean no action
If a connection breaks after sending a request, the sender may not know whether the record was created. Blind retries can create duplicates. Idempotency means repeating the same operation preserves its intended effect, a property MDN explains separately. It does not automatically apply to every request.
Check the particular API's documented protections: an idempotency key, lookup by external identifier or another mechanism. The example needs one request and a way to recover its number after an uncertain response. Merely saying the network is unavailable does not solve this.
Limits become part of the process
Request limits, file sizes, field availability and permission lifetimes affect operation after launch. Without planning for a large queue, an integration may demonstrate one record successfully and stop when requests accumulate. Test ordinary load and recovery after interruption.
Distinguish technical errors from content rejections. Temporary unavailability may permit a retry; an invalid address needs correction. Operators need distinct states and a way to resume after fixing the cause while retaining the original record's connection.
Accepting an integration
Ask to see one request travel from form to working record, then reproduce a retry and an agreed attachment-upload failure. Check where record relationships live, who notices incomplete transfers and how the process resumes. These questions reveal difficulties hidden by a successful demonstration request.
