Automation

Business API: a checklist to decide whether it makes sense for your organisation

Two people enter the same order into different tools. A customer completes a form and someone has to manually copy their details. Or an internal application needs to access information locked away in another system. In situations like these, a quick suggestion often arises: ‘we need a business API’.

Before making that decision, it is worth defining the problem it needs to solve. An API is a way for systems to communicate: it allows one application to request data from or perform an action in another, following defined rules. It can connect tools, supply a customer portal or automate repetitive steps. However, it also introduces decisions around data, permissions, errors and maintenance.

Use this checklist when considering creating, procuring or opening up an API to connect your company’s systems. By the end, you will be able to decide whether the case is sufficiently defined, which risks you need to address first, and whether you need a simple integration, an automation or a bespoke development.

Purpose of the review

Mark each check as yes, no or pending. The aim is not to collect technical terms, but to prevent a connection between systems from being built without a clear purpose.

The review has three layers:

Objective: what needs to change in your operations or in the experience of the person using the system.
Scope: which data, actions and tools are involved.
Solution: how the systems will connect and which controls they will need.

A business API makes sense when the connection helps complete a defined process. For example, in a hypothetical case, a request form could send data to a management application and create a task for the responsible team. The objective would not be ‘to have an API’, but to avoid duplicating information and ensure that every request reaches the appropriate workflow.

Initial checklist

Before discussing endpoints, credentials or data formats, check that the problem is clearly scoped.

You can describe the current process step by step, from the source data to the final action.
You have identified a specific task that is repeated, delayed or causes errors when data is passed between tools.
You know which person, team or customer will use the outcome of the connection.
You have defined an observable action that must take place at the end of the workflow: creating a record, updating a status, retrieving information or sending a notification.
You distinguish between what is essential in an initial version and what can wait.
You know which tool holds the primary data and which should be considered the reference if discrepancies arise.
A business stakeholder can validate the process rules, and someone can authorise the required access.
You have confirmed that the systems involved can be connected in the way you need, or that this possibility needs to be investigated.

If you cannot tick the first four boxes, it is not yet advisable to choose a technical solution. The problem may be solved by changing a procedure, configuring an existing tool or designing a more limited automation.

Functional checklist

This section defines what the business API must do from a business perspective. Avoid statements such as ‘connect the CRM to the website’ if they do not explain what information is transferred, when and with what outcome.

Each operation has a clear purpose: retrieve, create, update or delete information.
You have listed the minimum data each system must send or receive.
For each item of data, you know where it comes from, who can modify it and what happens if it is missing or invalid.
You have defined the relevant business rules, such as permitted statuses, mandatory fields, limits or prior approvals.
You have considered exceptions: duplicate records, incomplete data, repeated requests or information that no longer exists.
You know what the user should see when an operation fails and who should review the incident.
You can describe an acceptance criterion for each important workflow.

An acceptance criterion turns a general idea into something testable. For example, in a hypothetical scenario: ‘When a request is received with all mandatory fields completed, a record is created in the destination system and a confirmation is returned. If a mandatory field is missing, the record is not created and the reason is provided.’

It is also worth deciding what the first version will not do. If the API must cover orders, invoices, inventory, users and notifications from the outset, it is easy to combine processes with different owners and rules. Separating what is essential from what comes later reduces uncertainty and makes it easier to validate the main workflow.

Technical checklist

The technical element should translate functional requirements into controls that protect data and enable the connection to operate. You do not need to choose a specific technology yourself, but you should make the questions that need to be resolved clear.

An endpoint is simply a specific API address or function: for example, an operation to retrieve an order or update its status. Its name matters less than its contract: which data it accepts, what it returns, who can use it and how it responds when something goes wrong.

Security should not be limited to ‘adding a password’. If an integration can retrieve or modify customer, order or document data, you need to review what access it genuinely requires, who controls the credentials and how they are revoked when people, providers or tools change.

Maintenance checklist

An API does not end when it goes live. Changes to a tool, a business rule or a data field can affect the workflow even if the connection continues to respond. This section helps you decide whether you will be able to maintain it in a controlled way.

A person or team is responsible for reviewing incidents and deciding on functional changes.
The connected systems, the operations they perform and the data they exchange are documented.
The required accounts, access rights and credentials are known, as is their owner.
Changes to fields, permissions or rules are tested before being applied to the live workflow when they may affect it.
There is a way to detect failures, rejected requests or processes that are left incomplete.
A response to errors has been planned: retry, correct data, notify a person or stop an action.
Updates to an external system are reviewed for their potential impact on the integration.
It has been decided when an improvement requires changes to the API, the connected system or the business process itself.
Documentation is updated when the workflow changes, not only at the start of the project.

Maintenance also includes operational decisions. If an order does not synchronise, for example, someone needs to know where to check it, which data to review and whether they can correct it without creating a duplicate. Automation reduces manual steps, but it does not remove the need to define who is responsible when exceptions occur.

How to interpret the outcome

You do not need to reach a numerical score to reach a useful conclusion. Look at which section has the most no or pending responses.

The initial checklist is incomplete: define the process and objective more clearly. There is not yet a sufficient basis to decide whether you need a business API.
The functional section is incomplete: clarify data, rules and exceptions with the people who carry out the work. The connection could be developed, but it would be difficult to verify whether it delivers the expected result.
The technical section is incomplete: do not enable the integration until permissions, error handling and access to systems have been defined. These decisions affect security and process continuity.
The maintenance section is incomplete: assign owners, document the setup and establish a way to review incidents. Without this, a useful connection can become a difficult dependency to manage.
Most answers are yes: you already have a reasonable basis for assessing the scope of an integration. The next analysis should compare possible solutions according to your systems, rules and future development needs.

In some cases, a configuration available in the tools you already use will be sufficient. In others, the process rules, data or permissions will require a specific integration. If you would like to review which solution suits your workflow and what conditions it must meet before it is connected, you can tell AVSISTEC about your automation project.