An API (application programming interface) is a defined way for one piece of software to ask another for data or to do something, without either needing to know how the other works inside. When your website sends a new enquiry into your CRM, pulls live inventory from a supplier, verifies a payment, or checks a shipping rate, it is using an API.
The useful mental model is a service counter. There is a fixed set of things you can ask for, a required way to ask, proof that you are allowed to ask, and a predictable shape of answer. You never get to go behind the counter, and you do not need to.
What one actually looks like
A typical web API call is an HTTP request to a URL, called an endpoint, with the method describing the intent: GET to retrieve, POST to create, PUT or PATCH to update, DELETE to remove. The response comes back as structured data, almost always JSON, along with a status code saying whether it worked.
So “pull the last ten orders for this customer” becomes a GET request to an orders endpoint with the customer ID and a limit, carrying a credential that proves you are entitled to that data, and the answer is a JSON array your code can read. Everything else is elaboration on that pattern.
The styles you will meet
REST is the dominant style. Resources have URLs, HTTP methods describe the operation, responses are JSON. Nearly every service you integrate with offers one.
GraphQL lets the client specify exactly which fields it wants in a single query, which avoids both over-fetching and the many round trips REST sometimes needs. More efficient for complex data, more setup to build and cache.
Webhooks invert the direction. Instead of you asking repeatedly whether anything changed, the other system calls a URL on your site the moment something happens. For anything event-driven, a payment completing, a form submission, an order shipping, webhooks are almost always the right answer.
SOAP still turns up in banking, insurance, logistics and older enterprise systems. Heavier and XML-based, but perfectly workable.
Authentication, and the mistake to avoid
Most APIs require a credential: an API key, a token, or an OAuth flow where the user grants your application access without ever handing over their password. OAuth is what is happening when you click “connect your account” and get redirected to approve permissions.
The mistake worth stating plainly: credentials must never appear in client-side code or in a public repository. Anything in your site’s JavaScript is readable by anyone who views source. Keys belong in server-side environment variables or a secrets store, with calls made from the server. Keys leaked in front-end code and committed repositories are one of the most common ways small businesses get an unexpected bill or a compromised account.
Rate limits are the other constant. Services cap how many requests you may make in a period, and exceeding it gets you throttled or blocked. Any integration that runs at volume needs to respect them deliberately rather than discover them in production.
Where a business actually meets APIs
Forms into a CRM, so an enquiry arrives as a record with its source attached rather than as an email someone re-types.
Payments, where the gateway’s API keeps card data off your server entirely and your PCI scope small.
Membership and course platforms, syncing entitlements, subscriptions and access between systems.
Email marketing, pushing contacts and behavior into the platform that actually sends.
Booking and scheduling, so availability shown on the site is real.
Industry data feeds, such as property listings, supplier catalogues, or pricing.
Shipping and tax, calculating live rates at checkout.
Accounting, so orders become invoices without manual entry.
AI models, which are consumed almost entirely through APIs, including the retrieval systems behind an AI agent.
WordPress and APIs
WordPress ships with its own REST API at /wp-json/, which exposes posts, pages, users and custom content types, and which a custom plugin can extend with purpose-built endpoints. This is what makes WordPress usable as a headless CMS, and what lets external systems read from or write to a site programmatically.
Two things worth checking on any WordPress site. First, the REST API is enabled by default and some endpoints are readable without authentication, including one that can enumerate usernames; hardening what is publicly exposed is a standard part of securing a site. Second, most integrations are better built as a small custom plugin than as code in the theme, so that switching themes does not take the integration with it.
What goes wrong
Silent failure. The worst outcome by far. An integration stops working, nothing visibly breaks, and nobody notices until a month of leads never reached the CRM. Every integration needs logging and an alert when calls start failing.
No retry handling. Networks fail and services go down briefly. A single failed call should be queued and retried, not dropped.
Breaking changes. Providers version their APIs and retire old versions. An integration built and forgotten will eventually stop working on somebody else’s schedule.
Rate limits hit in production because nobody read them during the build.
Credentials in the wrong place, as above.
No test environment. Most serious providers offer sandbox credentials. Testing payment or data-writing integrations against live systems is how real orders get created by accident, which is one more argument for a proper staging environment.
Treating it as finished. An integration is a running dependency on someone else’s system, not a one-time build. It belongs in ongoing maintenance.
Custom build or connector tool?
Middleware such as Zapier or Make can connect two systems without custom code, and for low volumes and standard operations that is often the sensible, cheaper choice. We will say so when it is.
Custom integration earns its cost when volume makes per-task pricing expensive, when the data transformation is more than a field mapping, when you need reliable error handling and retries, when the systems involved have no connector, or when the integration is close enough to your revenue that you cannot accept a third party in the middle of it.
Building integrations between WordPress and the systems a business already runs on, CRMs, payment gateways, membership platforms, email tools and industry data feeds, is the substance of our API integration services. If you are re-typing data between two systems, or you suspect an integration has quietly stopped working, book a discovery call.
