Connecting Systems with APIs and Connectors

An API, or Application Programming Interface, is a set of definitions and protocols that allow one piece of software to request data or a service from another (Red Hat, 2024). Rather than needing developers to share the underlying code of an application, APIs expose a defined set of instructions that other systems can call safely and predictably (GOV.UK, 2024). Think of an API as a restaurant menu: it lists what can be ordered and how to ask for it, without revealing how the kitchen prepares each dish. This abstraction is central to API value, since it lets organisations expose useful functionality externally while protecting the complexity of internal systems (Jacobson, Brail and Woods, 2011).

Most modern APIs are accessed over the internet using HTTP, the same protocol that powers web browsing. A system sends a request to an endpoint, a defined web address representing a resource or action, and the API returns a response containing the requested data or confirmation, usually formatted as JSON (MDN Web Docs, n.d.). REST (Representational State Transfer) is the most widely used style of API design, relying on standard HTTP methods such as GET to retrieve data, POST to create it, PUT to update it, and DELETE to remove it. If a payroll system needs an employee’s leave balance from an HR platform, it sends a GET request to that platform’s leave endpoint and receives a response with the current figure, within seconds and without anyone re-typing information.

APIs already sit behind many everyday business processes: pulling live stock levels into an online store, sending calendar invites automatically from a booking system, updating a CRM when a new sales lead is captured, or triggering an alert when a support ticket is logged. Connecting internal systems through APIs can simplify back-end processes, cut development costs and speed up how quickly new services reach customers (McKinsey, 2017). Recognising these use cases is often the first step for organisations looking to reduce manual, repetitive administrative work.

Because APIs move data between systems, they need reliable ways to confirm who or what is making a request. An API key is a unique code assigned to an application, identifying it to the API and controlling what it can access. OAuth 2.0 is a more advanced authorisation framework that lets a user grant an application limited access to their data on another system without sharing a password, using time-limited tokens that can be revoked (Internet Engineering Task Force, 2012). Where an API key answers ‘which application is calling’, OAuth answers ‘has this user allowed this application to act on their behalf, and for how long’. Most business systems now rely on one or both methods to keep data secure.

Not every integration relies on one system repeatedly asking another for updates. A webhook flips this pattern: instead of the client polling an API at intervals, the server automatically sends data to a specified address the moment a chosen event happens, such as an order being placed or a form being submitted (Red Hat, 2024). This ‘push’ approach reduces unnecessary requests and delivers updates closer to real time, making webhooks a popular trigger for automated workflows.

Building a custom API integration requires technical skill: understanding authentication, formatting requests, and handling errors. Connectors remove much of this complexity. A connector is a pre-built wrapper around an API that lets an automation platform communicate with an external service through a simple, visual interface rather than written code (Microsoft, 2025). Native connectors, built and maintained by the platform provider for specific services such as Outlook or Salesforce, tend to be the most reliable and fastest to set up, since authentication and data formatting are handled automatically. Custom connectors, built around an organisation’s own or a lesser-known API, offer more flexibility but require more setup and ongoing maintenance. For most organisations, the practical choice is to check whether a native connector already exists before considering a custom API build, since this can save development time and reduce the risk of errors.