An API is an agreed way to use another system’s capabilities. A website may send an order to a CRM or request stock availability from accounting software. Systems do more than send text: they must share an understanding of fields, states and responsibility for the outcome. Integration therefore starts with exchange rules, not with obtaining an access key.
Requests and event notifications solve different tasks
When an answer is needed immediately, one system sends a request to another. When it needs to report a change, an external service may send a webhook. A website might request a price before checkout, while a payment provider reports confirmed funds later. Both need a protected connection, verification of the caller or sender and a clear response format.
| Situation |
What to agree |
|
Requesting current data |
Source, freshness and acceptable waiting time |
|
Creating an order |
Required fields and a shared identifier |
|
Status-change notification |
Sender verification and repeat-delivery behaviour |
A shared identifier matters more than a matching name
A product may have a short website name and an internal accounting name. Matching by name is unreliable because text changes, duplicates exist and languages differ. Agree stable identifiers for products, customers and documents, along with rules for creating records that do not yet exist in the other system.
Choose an authority for each field as well. If both the website and CRM can independently change a status or phone number, a conflict rule is needed. Last change wins is a rule too, but its consequences should be deliberately agreed with the business.
Learning scenario: the response was lost
The website sends an order, the CRM creates it, but the connection fails before the response arrives. Simply retrying may create another order. Associate the operation with a stable key and agree how an already accepted result can be found. Once connectivity returns, the team should see one business operation rather than guess which of two copies to process.
Not every error should trigger an automatic retry. A missing required detail needs a data correction, while temporary service unavailability may justify retrying. A useful log records the operation identifier, state and failure reason without storing passwords or secret keys in plain text.
How we prepare an integration for implementation
In ALL IT Agency’s API work, we break a technical task into events, fields and outcomes. Each exchange needs examples of a request, successful response and error. We check the test environment, available permissions and request-rate limits. Documentation alone does not confirm that a particular account has the necessary capabilities.
-
Describe who initiates the exchange and when it is complete.
-
Test retries, delays, access denial and invalid data.
-
Agree how the responsible person is notified and how manual recovery works.
What a completed integration means
One successful test request is only the start of verification. Acceptance should demonstrate consistent records in both systems, visible failures and retries that preserve the intended outcome. Hand over an exchange diagram, access ownership and an update procedure for external API changes. This keeps the connection a manageable part of the workflow.
Sources and further reading
