APIs and Integrations for Business Software, Explained

Most business software now talks to other software: a form that adds a lead to your CRM, a shop that takes card payments, an app that sends a confirmation email. These connections run through APIs. This guide explains in plain terms what an API is, the integrations businesses ask for most, how webhooks work, how to keep API keys safe, and what drives the cost and running limits of an integration. It draws on MDN Web Docs, OWASP and Stripe's developer documentation as a worked example, checked on 29 October 2026.

What an API is

MDN's introduction to web APIs describes Application Programming Interfaces as constructs that let developers "create complex functionality more easily", hiding the complicated parts behind a simpler interface. Its comparison is the plug socket: you plug in an appliance rather than wiring it into the mains yourself.

For business software, an API is the published way one system lets another ask it for something. Your website can ask a payment provider to take a payment, ask your CRM to create a contact, or ask a delivery service for a shipping rate. Each service documents what you can ask, what you must send, and what comes back. You do not need to know how the other system works inside, only how to use its API correctly.

Common integrations for businesses

  • Payments: card payments, subscriptions and refunds through a payment provider, so card details never touch your own server.
  • CRM and sales tools: website enquiries and quote requests go straight into your CRM with the source attached, instead of being copied from an inbox.
  • Email platforms: new customers are added to the right list, and the site sends receipts or reminders through a proper sending service. See our guide to email marketing rules for consent.
  • Accounting and invoicing: orders and payments create invoices or records in your accounting software.
  • Booking, maps, shipping and stock: calendars, addresses, delivery rates and stock levels kept in step between systems.
  • Your own mobile app: a phone app that uses the same API as your web app, so both share the same data and rules.

Webhooks: when the other system calls you

An API call is your system asking. A webhook is the other way round: the other system sends a message to an address on your server when something happens. Stripe's documentation on webhook endpoints is a clear example. It explains that webhooks let you respond to events that happen later, "such as when a customer's bank confirms a payment, a customer disputes a charge, or a recurring payment succeeds".

The same page shows three things any webhook handler should do:

  • Check the message is genuine. Stripe signs each event and recommends verifying the signature with its official libraries before acting on it. Otherwise anyone who finds the address could send fake "payment received" messages.
  • Expect duplicates. Stripe notes that endpoints "might occasionally receive the same event more than once" and suggests logging the IDs of events already processed, so an order is not fulfilled twice.
  • Be ready for retries. If your server is down, Stripe keeps trying to deliver events for up to three days in live mode. Your system should cope with events arriving late and out of order.

Other services differ in detail, but the same three questions apply to every webhook.

API keys: treat them like passwords

Most APIs identify your account with a key or token. Stripe's best practices for API keys describe secret keys as "a form of account credentials, like a username and password". If someone obtains one, Stripe warns, they "can make unauthorized charges, access customer data, or disrupt your integration". The same habits apply to any service:

  • Never put secret keys in source code. Stripe notes that attackers "continuously scan public repositories" for keys. Keep them in your hosting platform's secrets store or in environment variables.
  • Keep secret keys on the server. Only keys a service marks as public (Stripe calls them publishable keys) belong in web pages or apps.
  • Use restricted keys with only the permissions the integration needs, and limit who in your team can see or create them.
  • Rotate keys on a schedule and keep a plan for replacing one quickly if it leaks.
  • Own the accounts. The payment, CRM and email accounts should be in your business's name, with your developer added as a user, so keys can be reissued without them.

Security risks in your own API

When your web app or mobile app has its own API, it becomes something attackers can call directly, without going through your screens. The OWASP Top 10 API Security Risks (2023) puts Broken Object Level Authorization first: APIs expose endpoints that take record IDs, and "object level authorization checks should be considered in every function that accesses a data source using an ID from the user". In plain terms, changing an order number in a request must never show someone else's order.

The list also includes Broken Authentication and Unrestricted Resource Consumption, which OWASP notes can cause outages or "an increase of operational costs" when services such as email, SMS or phone calls are "paid for per request". Ask your developer how each item on the list is handled. Our website security guide covers the basics for the rest of your site.

Rate limits, failures and retries

Every API sets limits on how often you can call it. Stripe's page on rate limits explains that if you exceed them, requests are refused with a 429 Too Many Requests response, and advises treating limits as maximums and avoiding unnecessary load. Other services also have outages and maintenance windows.

A sturdy integration plans for this: it retries failed requests after a pause, queues work rather than losing it, logs what failed, and alerts someone when something keeps failing. Without this, a busy day or a brief outage at a provider can silently drop leads or orders.

What drives the cost of an integration

There is no standard price for an integration, because the same label covers very different work. The effort depends on:

  • Direction: sending data one way is simpler than keeping two systems in sync both ways.
  • Data mapping: how closely the fields in one system match the other, and what happens when they do not.
  • Volume and timing: a few records a day or thousands a minute, in real time or in a nightly batch.
  • Quality of the other API: clear documentation, a test environment and webhooks make the work faster.
  • Error handling and monitoring, as described above.
  • Running costs: many services charge per call, per message or by plan tier, on top of the build.

APIs also change. Providers release new versions and retire old ones, so budget for occasional updates. Our guides to what an app costs and writing a project brief help you describe the integrations you need.

Custom integration or an automation tool?

For simple, low-volume links, such as copying a form entry into a spreadsheet, a ready-made automation tool or the services' own built-in connectors are often enough and cheaper to start. A custom integration makes more sense when the data is sensitive, the volume is high, the logic follows your own business rules, or a failure would cost real money. Either way, write down what is connected to what, whose account it runs on, and who gets the alert when it breaks. Connecting an AI chatbot to your systems? See what to check before adding an AI chatbot.

Frequently asked questions

What is an API in simple terms?

It is the published way one piece of software lets another ask it for something, such as taking a payment or creating a CRM contact. You use what the API offers without needing to know how the other system works inside.

What is the difference between an API and a webhook?

With an API call, your system asks another system for something. With a webhook, the other system sends a message to your server when an event happens, such as a payment succeeding or a subscription renewing.

Where should API keys be stored?

Secret keys belong on the server, in the hosting platform's secrets store or environment variables, never in source code or in web pages. Use keys with limited permissions and rotate them on a schedule.

What happens if an API I depend on goes down?

Requests fail or are refused. A well-built integration retries after a pause, queues work instead of losing it, logs failures and alerts someone, so leads and orders are not silently dropped.

Do integrations have running costs?

Often, yes. Many services charge per request, per message or by plan tier, and APIs change over time, so budget for usage fees and occasional updates as well as the initial build.

Need your systems connected? See how we build integrations and automations in web application development, see all our services, or email info@creahive.com.