API

Every application you use has two faces. One is the interface built for people: screens, buttons, forms. The other is the interface built for software, and that is the API. It is a published set of requests the system will accept — list the users, create an invoice, read this record, change that setting — and the exact format in which it answers. A program that knows the format can operate the application without a person in the loop.

That is what makes most modern integration possible. When your ticketing system posts to Slack, when a website shows live inventory, when your identity provider creates accounts in a dozen other tools, an API is doing the work on both ends. Cloud services in particular are built API-first; the web interface you see is often just one more program calling the same API.

What an API call looks like

A request names the thing you want and includes a credential that proves who is asking. The system checks the credential, checks that this identity is allowed to do this thing, does it, and returns a structured answer — usually a block of text in a format called JSON that a program can parse. A single button click in a web console might correspond to one API call or to a dozen chained together.

Most APIs are documented publicly: the vendor lists every available request, what each one needs, and what it returns. That documentation is what a developer, or increasingly an AI coding tool, reads in order to write the integration.

Keys, permissions, and why they matter

Access to an API is granted through a credential — an API key, a token, or an application registration in the identity system. That credential carries a set of permissions, called scopes, that say which requests it may make. A read-only key can list records but not change them. A key scoped to one client’s tenant cannot see another’s.

This is where the operational risk lives. An API key is a password that never gets typed by a person, so it rarely gets rotated, often gets pasted into scripts and configuration files, and frequently carries more permission than the job needs. Treat API credentials the way you treat administrator passwords: stored in a vault, scoped to the minimum, rotated, and assigned to a service account rather than a person.

Vendors expose everything; that is not always what you want

An API usually lets a program do everything the application can do, including things nobody should do by accident, like permanently deleting every file. When you connect an AI model or an automation to a system, the question is not what the API allows but what you choose to allow through it. That filtering is one of the main reasons organizations put a layer of their own — such as a custom MCPAPIs define how software communicates with software. MCPs (Model Context Protocol) let AI models connect to tools directly — no custom integration code needed. connector — between the model and the raw API, rather than handing the model an all-powerful key.

Where it shows up in practice

Onboarding and offboarding automation, monitoring that pulls readings from firewalls and switches, reports that combine analytics with sales data, AI assistants that read tickets and post summaries: all of it is API traffic. When a vendor’s API is missing or limited — common with the cheaper tier of a product — the fallback is a browser automation that clicks through the human interface instead, which works but is slower and more fragile. Whether a platform has a good API is worth asking before you buy it.