APIs: how to connect your business software
Updated on
A prospect completes your form. Someone copies the request into the CRM, creates a task and looks for the right folder to store the attachments. The software exists, but your team is still doing the travelling between the systems, one operation at a time.
An API can allow those systems to exchange information. This is the idea I explain in the video: understanding how two parts of an application, or two different applications, communicate. For a business, the value becomes clearer when the concept is connected to a specific workflow rather than an abstract technical promise.
Contents
An API defines how a system can be used
An API is an interface describing operations a piece of software makes available and how to request them. Depending on the permissions granted, another application might read a record, create a contact or update a status. Access to one operation does not imply access to everything the software can do.
In a web application, the interface in the browser may send a request to a server. The server processes it and returns a response. JSON is a common data format for those exchanges, although it is not the only possibility. See MDN’s introduction to client-server interactions.
The API does not automatically translate the rules of your business. It provides ways to exchange information. You still need to decide which data moves, when it moves and what each system should do with it. Those decisions turn technical access into a useful business process.
An example: from a website form to a customer record
Imagine a business receiving requests for work. Its form collects a name, contact details, project type and a short description. An integration could check whether the contact already exists, then create an inquiry connected to the correct record. The steps should follow a defined rule rather than assume every submission represents a new customer.
The salesperson can then see the context without copying it manually. A follow-up task could be created if the process calls for one. This is an illustrative workflow, not a measured client outcome or a claim that a particular company already uses this exact configuration.
Several choices make the workflow reliable: which system owns the contact details, how duplicates are recognised and what happens if the person uses another email address. These details shape the quality of the integration more than the fact that the first test request succeeds.
A website connected to a CRM should be discussed as that complete journey. Simply saying the tools are connected leaves out the work that makes the connection valuable to the team, including what happens when an inquiry is incomplete or ambiguous.
Plan for an exchange that fails
A service can be unavailable. A field can be missing. A request can succeed while its response fails to arrive. The system needs to handle those situations without losing the inquiry or duplicating it on the next attempt. Reliable operation includes more than the ideal path through the demonstration.
Plan usable logs, appropriate alerts and recovery rules. The team should know how to find an outstanding request and when human intervention is necessary. A technical error message alone is not a useful handover if nobody knows which customer or task it concerns.
Give access rights the same attention. A connection should not receive more permissions than its job requires. Authentication information needs to be managed on the server where appropriate, without exposing it to website visitors. Identify who manages that access and how the connection will be maintained over time.
Verify feasibility before promising a connection
Software products expose different operations. Some features depend on a subscription, special authorisation or usage limits. Examine the provider’s documentation and conditions during scoping. An available integration label does not establish that every required field or action is supported in the proposed setup.
An API also does not guarantee that both tools define their information in the same way. A customer, project or order can mean different things on either side. Map those meanings and decide what happens when information changes. Otherwise, the exchange may work technically while creating confusion for the people using the records.
Comparison: CSV transfer, existing connector or custom integration
There are several ways to move information between systems. Compare frequency, business rules and monitoring effort. An available API does not automatically make custom development necessary, and a manual file transfer is not automatically unsuitable for every task.
Exporting and importing a CSV file
Consider it for: periodically transferring a batch when a delay is acceptable. Strength: the team can examine the file before importing it. Limitation: someone remains responsible for columns, duplicates and each transfer. This may suit a one-off operation or a modest volume. It becomes burdensome when the task repeats throughout the day or several people handle competing copies of the same file.
Using a connector offered by the software
Consider it for: linking two tools when their existing connection covers the intended journey. Strength: you start with a workflow the provider has already designed. Limitation: fields, direction, subscription requirements and recovery options need checking. A connect button does not tell you whether updates travel both ways or how duplicates are handled. Try your own scenarios with demonstration data before relying on the connection.
Developing an integration for your process
Consider it for: particular rules, several systems or exceptions existing connectors handle poorly. Strength: the exchanges can follow the business process you define. Limitation: maintenance needs funding and ownership. Providers’ APIs may change, and someone must monitor those changes and verify continued operation. The proposal should cover logs, recovery and documentation rather than only the first successful request.
These options can coexist. An initial migration might use a file, while new inquiries later move through an automated connection. Define the boundary between them so records already imported are not created again. The sequence of operations matters as much as the tool chosen for each stage.
Write an exchange specification before development
For each data item, record its origin, destination and update rule. A form might initially provide an email address while the CRM becomes the reference afterwards. If the address changes in the CRM, should that change return to the website? The answer depends on what the site does, including whether it provides a customer account.
Think about stable identifiers. A company’s name can change and two people can share a name. The technical team needs an explicit rule for finding the correct record, plus a way to handle uncertain matches. Do not confuse an easy demonstration using tidy examples with dependable operation on real information.
Describe how to recognise a completed operation. A notification does not necessarily prove that every destination has saved the data. Your acceptance scenarios can include creation, modification, duplication, missing information and recovery after interruption. These checks let you evaluate the integration through observable outcomes rather than a vague assurance that the systems communicate.
Questions to bring to your project discussion
Identify the task your team repeats between two tools. Specify the information that must move and what should remain in its original system. Decide when the exchange is needed, who handles exceptions and how the team will confirm that the information arrived correctly. Use an actual workflow to make these questions concrete.
Those answers help scope automation for your business. The objective is a dependable, understandable and maintainable journey that the team can follow in everyday work. Technical connectivity is useful when it supports that outcome, not simply when two systems display a connected status.
FAQ: connecting business software through APIs
Does an API replace a CRM or ERP?
No. It lets another system use selected functions that the software exposes. The CRM continues to handle the information and workflows in its configuration; the ERP retains its operational role. Integration connects those functions. It does not automatically create a common management model, reconcile conflicting definitions or decide which system should own each record.
Is information always synchronised immediately?
Not necessarily. An exchange may be triggered by an event or run at regular intervals. The choice depends on what the tools support and the delay the business can accept. Define that delay during scoping, together with what staff see while information is still waiting to move and who investigates an overdue exchange.
What if a tool lacks the required API function?
Check other options authorised and documented by the provider, such as export, import or an existing connector. A manual step may remain reasonable if it is occasional and clearly assigned. Before working around a limitation, evaluate the effort and fragility involved. A promised connection should always be based on verified feasibility for the actual workflow.
Which connection should we implement first?
Choose a frequent, well-understood journey whose errors can be detected. Moving a website inquiry into the CRM is often straightforward to describe, but its priority depends on your business. When planning a CRM-connected website, bring an example request and explain what the team should be able to find after receiving it.