API: what it is and how it connects applications

An API—Application Programming Interface—is the piece of software that lets two applications understand each other. When you book a flight and the airline checks hotel availability to offer you a package, an API connects both systems. When your CRM updates upon receiving a new lead from your website, an API pushes the data. When you ask an AI tool to summarize a document, an API transmits your request to the model and returns the response.

APIs are invisible to the end user. But the modern internet runs on APIs: every application talking to every other one, every cloud service exposing capabilities, every company opening up its system to integrations that multiply its value. Understanding what an API is—and especially what decisions integrating one involves—is essential for any team that operates digital products or automates processes.

This article explains what an API is exactly, how it evolved into today's model, the main types worth knowing (REST, GraphQL, webhooks), the canonical examples that are now references (Stripe, Twilio, OpenAI), and the mistakes teams repeat when integrating.

What it is exactly

An API is a contract between two systems: the rules by which one program can ask another for information or actions, and the rules by which the other responds.

A concrete example: imagine a service that delivers the current price of bitcoin. Without an API, you'd have to open its website, read the number, and copy it. With an API, your program makes a specific request (something like "GET /v1/prices/BTC"), the service returns a structured response (typically JSON: {"price": 65432, "currency": "USD", "timestamp": "2026-05-05T12:00:00Z"}), and your program can use it automatically.

APIs define:

• What can be requested (endpoints, methods, parameters).
• How it must be requested (format, authentication, headers).
• What gets returned (response format, status codes, errors).
• What limits exist (rate limiting, quotas, pricing plans).
• What security rules apply.

A team integrating someone else's API doesn't need to understand how it's built inside; it only needs to understand the contract. And a team offering an API should document it with the same discipline used for a legal contract: ambiguities cost time, money, and trust.

The historical journey worth knowing

The concept of "an interface for one program to talk to another" is as old as programming. What has changed is how and at what scale.

1960s-70s: APIs as subroutine libraries. The term started appearing in technical literature from IBM and other manufacturers in the 1960s. APIs were libraries of functions that a programmer called from their code—think math libraries, file management, operating system. They lived inside the same machine.

1980s-90s: APIs in distributed systems. With networking came protocols like CORBA (1991) and DCOM (Microsoft, 1996) so that applications on different machines could call each other. They were complex, heavy, and fragile—but they opened the door.

1998-2000: the web starts to become API. SOAP (Simple Object Access Protocol, 1998) brought an XML-based protocol for web services. Salesforce launched its API in February 2000, a decision considered foundational—it was one of the first major SaaS companies to expose its functionality so third parties could build on top of it. eBay launched its API the same year. Amazon opened its Product Advertising API in July 2002 (another decision that changed the ecosystem).

2000: REST. Roy Fielding, in his doctoral dissertation at UC Irvine, Architectural Styles and the Design of Network-based Software Architectures (June 2000), formalized REST (Representational State Transfer). REST became the dominant architectural style for web APIs because of its simplicity: it used the HTTP protocol that already existed, identified resources with clean URLs, and let developers work with JSON or XML as convenient.

2004-2007: the era of public APIs. Flickr opened its API in 2004, Twitter in 2006, the Facebook Platform in 2007. The idea of "building on other people's data" went from novelty to standard. The ProgrammableWeb directory appeared (2005), cataloging thousands of public APIs.

2008-2010: APIs as a product. Twilio was founded in 2008 and popularized the idea of "API as a product": selling the integration as the main product, with no user interface for humans. Stripe, founded in 2010 by brothers Patrick and John Collison, took that idea to another level with an API considered an object of technical admiration. Stripe became the benchmark: impeccable documentation, clear errors, obsessive ergonomics. Any team designing a modern API looks to Stripe.

2012-2015: redesigning the conversation. Facebook released GraphQL internally in 2012 and open-sourced it in 2015. GraphQL addressed a real problem with REST APIs: the client receives what the server decides, not what the client needs—which produces responses that are either too large (over-fetching) or require multiple calls (under-fetching). With GraphQL, the client declares exactly what data it wants and the server responds in that shape. It's popular in complex applications with many screens and related data.

2015: gRPC. Google released gRPC, a modern RPC framework based on HTTP/2 and Protocol Buffers. It works better than REST for communication between internal services where performance matters.

2017-2020: APIs as basic infrastructure. Postman (a client for testing APIs) becomes standard, OpenAPI/Swagger consolidates as a documentation format, and an entire industry of API gateways (Kong, Apigee, AWS API Gateway), monitoring (Datadog, New Relic), and testing emerges.

2022-2026: AI APIs. With the launch of GPT-3 (June 2020), ChatGPT (November 2022), Claude (Anthropic, March 2023), and Gemini (Google, December 2023), APIs become the primary interface for accessing generative AI models. The conversation shifts: now an API doesn't just deliver data—it can generate text, images, code, decisions. The APIs of OpenAI, Anthropic, and similar providers become central pieces of modern software, with their own quirks (variable latency, per-token costs, context management).

Types of APIs worth knowing

REST is still the most common. A REST API exposes "resources" (users, products, orders) with clear URLs, manipulated with HTTP verbs (GET to read, POST to create, PUT/PATCH to update, DELETE to remove). Most public APIs you encounter today are REST.

GraphQL is used when client flexibility matters: applications with many different views, dashboards, mobile apps where minimizing transfer matters.

gRPC is used between internal services in modern architectures (microservices) where speed and strict typing matter more than ease of inspection.

SOAP survives in companies with legacy integrations—banking, insurance, public administration. If you work in traditional sectors, you'll run into it.

Webhooks are the inverse: instead of your system asking the other one, the other one notifies you when something happens. The term was coined by Jeff Lindsay around 2007. Stripe notifies you when a payment completes; Slack notifies you when someone sends a message to a channel. More efficient than constantly asking, and more real-time.

Streaming APIs (WebSockets, Server-Sent Events) open permanent connections for continuous data flows: stock quotes, real-time chat, geolocation updates.

AI / LLM APIs: technically they're REST, but with quirks. They receive text and return generated text; they charge per token (units of processed text); they can take seconds per response; they support streaming the response as it's generated.

Authentication: how access is controlled

Almost no real API is completely open. Some kind of credential controls access.

API key: a unique token assigned to each client. Simple, widely used for non-critical public APIs.

Basic auth: username and password on every request. Simple but limited.

OAuth 2.0 (IETF standard from 2012, RFC 6749): the dominant protocol for delegated authentication. It's what happens when an app asks for "permission to access your Google Calendar" without asking for your password: it redirects you to Google, you authorize, and the app receives a token with specific permissions.

JWT (JSON Web Tokens): cryptographically signed tokens that contain user information. Heavily used in modern APIs.

mTLS (mutual TLS): certificate-based authentication, for machine-to-machine APIs in high-security contexts.

The choice depends on the risk of the exposed resource and the type of client. For internal APIs, JWT or API key. For third-party access to user data, OAuth 2.0. For banking and sensitive data, mTLS and additional authentication.

Canonical examples: the APIs people admire

Stripe: probably the most praised API in the industry. Clear endpoints, impeccable documentation, precise error messages, testing tools, well-solved idempotency (you can retry a request without creating duplicates). Any team designing an API studies Stripe.

Twilio: an API for sending SMS, voice, and video. A pioneer of the "API as the main product" model. Documentation with examples in multiple languages.

Slack API: webhook examples, well-implemented OAuth, interactive documentation.

OpenAI / Anthropic: AI model APIs. Relatively simple design for the complexity of the service they deliver. Token streaming. Built-in quota and cost handling.

Mapbox / Google Maps: maps and geolocation APIs. Use cases from simple visualization to complex routing.

Mailgun / SendGrid / Postmark: APIs for transactional email sending.

Studying the documentation of these APIs before designing your own or evaluating others is one of the best exercises for a technical team.

Typical integration cases in a marketing team

It's not only developers who integrate APIs. Marketing teams use them, directly or via no-code tools, to:

• Sync leads between a web form and a CRM (HubSpot, Salesforce, Pipedrive).
• Send transactional email (Mailgun, Postmark, SendGrid).
• Pull social media metrics (Meta Graph API, X API, LinkedIn API).
• Publish scheduled content on social media.
• Process payments in e-commerce (Stripe, PayPal, Adyen).
• Verify emails or enrich data (Clearbit, Apollo, ZeroBounce).
• Connect tools through automation (Zapier, Make, n8n) that orchestrates APIs without code.
• Access generative AI for content production or transcription.

iPaaS platforms (Integration Platform as a Service)—Zapier since 2011, Make (formerly Integromat) since 2012, n8n more recently—democratized the use of APIs without needing to program, letting non-technical teams design automated flows.

Operational decisions before integrating an API

Five critical questions before investing time in an integration:

Does it comply with the terms of use? Some APIs prohibit commercial uses, content scraping, or require specific disclosures. Reading the TOS before building on them avoids forced rebuilds.

What happens when it fails? Every API fails. What matters is how. Does your integration degrade gracefully (graceful degradation) or crash completely? Are there automatic retries? Are there alerts?

What does it cost at scale? Commercial APIs usually charge by volume. An integration that costs €10/month in testing can cost €10,000/month in production. Read the pricing and simulate scenarios.

Does it meet regulations? GDPR, HIPAA if it's health, PCI-DSS if it handles cards. An API can be technically perfect and disqualify you legally if the data ends up where it shouldn't.

What happens if the API changes or disappears? APIs change. Companies get acquired, products get discontinued. A deep integration with a fragile API is technical debt. Do you have a plan B?

Mistakes that repeat in every integration

Not reading the documentation. The most expensive and common mistake. The documentation of serious APIs contains the details that prevent problems: limits, rate limits, idempotency, specific errors.

Hardcoding the API key in the code. Credentials belong in environment variables or secret managers (AWS Secrets Manager, HashiCorp Vault, Doppler), never in the code repository. An API key leaked on GitHub can cost thousands before you detect it.

Not handling errors. Assuming the API always responds correctly and building without try/catch or retries. The first time the service goes down, the integration breaks.

Ignoring rate limiting. Making 10,000 requests per minute to an API that allows 60 gets your IP blocked and, per the TOS, your account suspended.

Not verifying webhooks. Webhooks that arrive without cryptographic verification are an attack vector: anyone can send fake requests. Always verify the signature.

Logs with sensitive data. Logs useful for debugging that end up recording passwords, tokens, or personal data. Logs are the most common source of credential leaks.

Not versioning the integration. APIs evolve. Building against "the latest version" without pinning produces surprise breakage when the API changes. Serious APIs have versioning (v1, v2) and give migration time; take advantage of it.

Excessive coupling. Building your product so tightly tied to a specific API that switching is impossible. A minimal abstraction layer protects against changes or a change of provider.

Naive synchronization. Poorly designed two-way syncs produce infinite loops, conflicts, and duplicate data. The sources of truth and the conflict-resolution rules must be decided explicitly.

Not documenting internally. An integration that only the person who built it understands becomes fragile when that person leaves. Document which API, with which credentials, what it does, and what failures to watch for.

How to fit APIs into creative operations

The use of APIs in creative operations has multiplied: asset management, automatic publishing, AI transcriptions, centralized metrics, syncing between tools. Without a system, each integration is a local decision with no documentation, and invisible debt piles up.

Creative operations are what bring order to that chaos. At Polimake, Studio defines which tools are used and how they integrate (which API connects with which); Studio coordinates the automated flows (publishing, approvals, notifications); Media runs asset-specific integrations (DAM, transcription, export to channels).

This relates to the decision about the hosting each integration lives on, the choice of CMS that usually offers its own API, and the broader practice of automation.

To wrap up

APIs are the silent infrastructure of modern software. Every tool you use in marketing, every publishing platform, every payment system, every accessible AI model—it all rests on APIs. Understanding them isn't optional for anyone who manages digital products or automates processes: it's basic literacy.

The practice that ages best: treating each integration as an investment that requires documentation, monitoring, and maintenance, not as a shortcut "that already works." A well-designed integration lasts years; an improvised one breaks within six months and leaves someone putting out fires on a Friday afternoon.

Quick references

• API = a contract between two systems. It defines what is requested, how, and what is returned.
• REST is still the dominant standard. GraphQL when you need to minimize transfer. gRPC between internal services.
• Webhooks reverse the direction: the server notifies you when something happens.
• OAuth 2.0 for delegated access to user data. API key for simple cases.
• Stripe, Twilio, OpenAI: canonical examples to study.
• iPaaS (Zapier, Make, n8n) democratizes APIs without code.
• Before integrating: TOS, failure handling, cost at scale, regulation, plan B.
• Never hardcode credentials. Environment variables or a secret manager.
• Handle errors and rate limits from day one.
• Verify webhook signatures.
• Versioning and abstraction so future changes don't break your product.
• Internal documentation is part of the integration, not something separate.