What Is a REST API? A Plain-English Guide for Business

A visitor fills in a form on your website, and within a second the lead appears in your CRM, a WhatsApp message goes out to them and your sales manager gets a notification. There is no magic behind this, just a handful of API requests passing between systems. In most cases those requests go through a REST API, the most common style for building interfaces between pieces of software.

You don't need to be a developer to understand how it works. Knowing the basic principles is enough to ask the right questions before you choose a platform, to understand why a "simple" integration takes a week, and to know what to ask of your vendor or developer.

In this guide we cover:

• what an API is and what a REST API is;
• the six principles REST is built on;
• what a request looks like: URLs, methods, status codes and authentication;
• how REST differs from SOAP, GraphQL and webhooks;
• where REST APIs show up in everyday business and how to plan an integration without expensive mistakes.

What an API is and why it matters for your business

An API (Application Programming Interface) is a set of rules that defines how one piece of software asks another for data or for an action. Think of it as a waiter in a restaurant. You don't walk into the kitchen; you place an order from the menu, and the waiter brings you the dish. The menu is the API documentation, the order is the request, and the dish is the response.

When you open a website, your browser sends a request to a server and gets a page back. But every website and every business system runs on its own server and stores data in its own way. An API lets both sides understand each other without either one needing to know how the other is built inside.

For a business, this matters for three reasons:

• Connecting systems. Your website, CRM, payment provider, accounting software and your Google and Meta advertising all talk to each other through APIs.
• Automation. Tools like n8n, Make and Zapier are essentially a convenient layer on top of thousands of APIs. We wrote a detailed guide to n8n for business if you want to go deeper.
• Choosing software. A system without an open API, or with a very limited one, quickly turns into a data island that you can't connect to anything else.

What a REST API is

REST (Representational State Transfer) is an architectural style for building APIs. The term was defined by Roy Fielding in his doctoral dissertation in 2000. Fielding was also one of the principal authors of the HTTP specification, which is why REST and HTTP fit together so naturally.

It's important to understand that REST is neither a protocol nor a piece of software. It's a set of principles and constraints, and an interface built according to them is called RESTful. REST has no methods of its own: in practice it almost always runs over HTTP and exchanges data as JSON, and less often as XML. Still, REST is not the same thing as HTTP, and not every interface that works over HTTP is truly RESTful.

What a resource is

All of REST's principles revolve around one idea: the resource. A resource is any unit of information that has an address: a lead, a customer, an order, a product, a blog post, an image file. Every resource has a stable address (a URL), and you perform actions on that address. For example, /leads is the collection of all leads, and /leads/1542 is one specific lead.

The six principles of REST

Fielding defined six constraints. Five are mandatory and one is optional. You don't need to memorise them, but they explain why REST APIs behave the way they do.

1. Client–server separation

The server stores and processes the resources, and the client (a website, an app, another system) requests them. Each side evolves independently. If you redesign your website or launch a mobile app, nothing needs to change on the server as long as both sides speak the same language. This is exactly what lets you connect your website, your app and your email platform to the same CRM.

2. Stateless

The server doesn't remember previous requests. Every request has to carry all the information needed to handle it, including identification and authorisation. If the client wants the next page of a lead list, it sends a complete new request rather than "give me the next one". This is how a server can handle thousands of clients at once, and why a single lost request doesn't break the whole process.

3. Cacheable

A response can state whether it may be cached and for how long. A product list that changes once a day can be cached; real-time stock levels can't. Sensible caching takes load off the server and makes your website faster.

4. Uniform interface

Every resource is accessed the same way: the same methods, the same response format, the same error conventions. Once you've learned to work with leads, you'll immediately understand how to work with orders. In its strictest form, this principle also requires responses to include links to the next possible actions (known as HATEOAS), but most commercial APIs settle for good documentation instead.

5. Layered system

There can be intermediary servers between the client and the server: a CDN, a firewall, a load balancer, a caching layer. Neither side needs to know how many layers sit in between. This makes it possible to add security and scale the system without changing the code of the clients.

6. Code on demand (optional)

The server can send the client code to execute, such as JavaScript. This is the only constraint that isn't mandatory, and most business APIs don't use it.

What a REST request looks like: URL, method and response

A REST request is built like a sentence: the URL is the noun and the method is the verb.

HTTP methods and CRUD

Most operations on data boil down to four actions: create, read, update and delete (CRUD). HTTP has a method for each:

• GET – read a resource or a list. For example, GET /leads?status=new returns all new leads.
• POST – create a new resource, such as a lead from a website form.
• PUT – fully replace an existing resource.
• PATCH – partially update a resource, for example change only the lead's status.
• DELETE – delete a resource.

What's inside a request and a response

Besides the URL and the method, a request includes headers, such as the content type and the access key, and sometimes a body with data in JSON format: name, phone number, lead source. The server replies with a status code and a JSON body.

Status codes worth knowing

• 200 OK – everything worked.
• 201 Created – the resource was created.
• 400 Bad Request – the request is invalid, for example a required field is missing.
• 401 Unauthorized / 403 Forbidden – the caller isn't properly identified or doesn't have permission.
• 404 Not Found – the resource doesn't exist. We covered the same code on websites in our guide to what a 404 error is.
• 429 Too Many Requests – you've exceeded the rate limit.
• 500 and above – something went wrong on the server side.

Authentication and security

Most business APIs require authentication: an API key or token in the Authorization header, or OAuth 2.0 when a user grants an app access to their account, as when you connect to Google or Meta. All traffic should go over HTTPS only. Treat an API key like a password: never put it in code that runs in the browser and never paste it into a chat.

REST vs SOAP, GraphQL and webhooks

REST isn't the only way to connect systems. It's worth knowing the alternatives, because you'll come across them in the documentation of different platforms.

SOAP

An older, stricter protocol based on XML and predefined contracts. It's still common in enterprise software, banking and some public-sector systems. It's more cumbersome to develop against, which is why most modern services have moved to REST.

GraphQL

A query language in which the client asks for exactly the fields it needs, in a single request to a single endpoint. This avoids transferring unnecessary data and cuts down the number of requests. Platforms that offer GraphQL as their main interface include monday.com and Shopify. So before you plan an integration, check which kind of API the platform provides. Automation tools hide some of the differences, but not all of them.

Webhooks: when the system calls you

With REST, the client asks and the server answers. If you want to know about every new order, you could ask every minute "anything new?" (polling), but that's wasteful. A webhook reverses the direction: the system sends an HTTP request to an address you've configured the moment an event happens, such as a successful payment or a form submitted on your website.

In practice, most integrations combine the two: a webhook announces that a new lead has arrived, and REST requests fetch additional details and create a record in the CRM. When you receive a webhook, always verify its signature to make sure the request really came from the system and not from someone who guessed the URL.

Where REST APIs meet your business

Even if you've never written a line of code, you already rely on REST APIs every day. Here are some common scenarios:

• Website form → CRM. A lead from a Webflow or WordPress form is sent to HubSpot, monday CRM or another system, together with the campaign source and UTM parameters. We explained how to pick a system and what to check in our guide on how to choose a CRM for your business.
• Content management. Webflow has a Data API for managing CMS items, and WordPress has a REST API built into its core. This lets you update a catalogue, prices or articles from an external system.
• Payments and invoicing. Most payment providers and invoicing tools offer APIs and webhooks: a successful transaction automatically creates an invoice and updates the order.
• Advertising and measurement. The Meta Conversions API and the Google Ads API let you send conversions from your server, even when ad blockers and privacy restrictions limit what the browser pixel can see.
• Messaging channels. The WhatsApp Business Platform (Cloud API) lets you send service messages and reminders from your business systems.
• Artificial intelligence. OpenAI, Anthropic and Google offer APIs for connecting their models to your website, chat or workflow. This is how chatbots and AI agents are built, as we described in our guide to AI agents for business.
• Reporting. Pulling data from your website, CRM and ad accounts into a spreadsheet or Looker Studio once a day instead of copying it by hand.

How to plan a REST API integration, step by step

A good integration starts with planning, not code. This is the order of work that prevents most failures.

Step 1. Define the business process

What triggers the integration, what data moves where, and what happens when something goes wrong. A sentence such as "every website lead goes into the CRM with its campaign source, and if the CRM is unavailable, an email alert is sent" is worth more than any diagram.

Step 2. Read the documentation

Check whether there is an API at all, which subscription plan includes it, which resources and actions it supports, how authentication works and what the rate limits are. Good documentation usually includes an OpenAPI specification and examples. If a system you're considering has no documented API, treat that as a warning sign.

Step 3. Choose the tool

For simple workflows, Zapier or Make is usually enough. For complex processes with logic and large data volumes, n8n or custom code on a server or in a cloud function is a better fit. Before you build, test the requests in Postman or Insomnia against a sandbox environment, if the vendor offers one.

Step 4. Handle errors and limits

Every API fails sometimes. Plan for retries with exponential backoff, handling of 429 responses and prevention of duplicates. Some APIs support an idempotency key, which guarantees that a request sent twice won't create two transactions. On top of that, log every failed request and alert a named person.

Step 5. Secure it and protect personal data

Keys belong in environment variables or a secrets manager, never in the code. Give each integration only the permissions it actually needs. Because most integrations move customers' personal data, you need to stay compliant with data protection rules. In the EU that means the GDPR and, for cookies and electronic marketing, the ePrivacy rules: know which data is transferred, to which vendors and to which countries, and make sure you have data processing agreements in place. This is general information, not legal advice.

Step 6. Test, document and monitor

Test edge cases: an empty field, a name with accented or non-Latin characters, a phone number in international format, special symbols. Document what is connected to what and where the keys are stored. After launch, keep an eye on API version announcements, because vendors deprecate old versions.

Common mistakes when working with APIs

• Choosing a platform without checking its API. Six months later you discover the API is only available on the most expensive plan, or that it lacks the action you need.
• An API key in your website code. Anyone who opens the browser's developer tools can copy it. Requests that use secret keys must go through a server or a cloud function.
• No error handling. The integration fails silently, and leads disappear for weeks before anyone notices.
• Ignoring rate limits. A nightly sync of thousands of products gets blocked halfway through with a 429 error.
• Duplicates. A retry without a deduplication mechanism creates two customers or two invoices.
• Character encoding issues. Text sent without UTF-8 arrives as question marks or gibberish, especially names with accents or non-Latin scripts. Always test with real data in every language your customers use.
• No documentation and no owner. The employee or freelancer who built the connection has left, and nobody knows where it runs or what it does.
• Running on an outdated version. The vendor announces in advance that an API version will be retired, the notice lands in an inbox nobody reads, and the integration stops working.

How RJL Studio connects your business systems

We build integrations between Webflow and WordPress websites and CRM, payment, email marketing, WhatsApp, advertising and AI tools. We start by mapping your business process, review the API of every system involved, and choose the simplest approach that will keep working over time: Make, Zapier, n8n or custom code. Every connection comes with error handling, alerts and documentation, so you always know exactly what is connected to what.

Read more about our automation and integration services and Webflow development, or get in touch and we'll come back to you with a proposal for connecting your systems.

Frequently asked questions

What is the difference between an API and a REST API?

An API is any interface through which pieces of software communicate. A REST API is an API built according to REST principles: resources with stable addresses, standard HTTP methods, stateless requests and responses in a consistent format, usually JSON. It is the most common type of API in web services today.

Do I need to know how to code to use a REST API?

Not always. Tools like Zapier, Make and n8n let you connect systems through a visual interface, and many of them include a generic HTTP module that works with almost any API. Still, understanding methods, status codes and authentication is very valuable: it helps you diagnose problems and design the process correctly. For complex integrations, it's worth involving a developer.

What is the difference between a REST API and a webhook?

With a REST API, your system contacts the server and asks. With a webhook, the server contacts you on its own the moment an event happens, such as a payment or a new form submission. Most integrations use both: the webhook announces the event, and REST requests fill in the details and carry out the actions.

Is a REST API secure?

REST is an architectural style, so security depends on the implementation: HTTPS only, keys or tokens stored on the server side, minimal permissions, signature verification for webhooks and rate limits. Most data leaks in integrations come from a key exposed in code or shared in a chat, not from a weakness in REST itself.

How can I check whether a system I'm considering will connect to my website and CRM?

Look for the developer documentation on the vendor's website (usually labelled Developers or API), check which plan includes API access, which actions it supports, whether it offers webhooks and what the rate limits are. It's also worth checking whether a ready-made connector exists in Zapier, Make or n8n. If there's no documented API, treat it as a risk before you sign up for a subscription.