At some point in most projects, someone asks whether the business needs its own API. Asked that way, it tends to end with something being built that nobody needed. A better starting point is where your business logic should live: copied into every screen your customers and staff use, or kept in one place behind them.
An API is less exotic than it sounds
An API is a defined way for one system to ask another for something: take this payment, give me this customer record, tell me what this order is worth. The two systems agree on which questions can be asked and what the answers look like.
If your organisation runs on more than one tool, you already depend on several APIs, whether anyone calls them that or not. Your website talks to a payment provider. Your CRM collects form submissions. So you have APIs already. What’s left to decide is whether to run one of your own on top of everyone else’s.
Start with the direct call
The least expensive way to connect to a third-party service is to call it directly. Your application asks the provider’s API a question, gets an answer and shows it. There’s nothing new to build and nothing new to keep running, and it’s the right choice far more often than people building their first product expect.
Direct doesn’t mean from the visitor’s browser. In almost every case the request goes server to server, from the server your site already runs on, so nothing secret leaves it.
Every layer you put between your front end and a provider is code somebody has to maintain, deploy and debug at two in the morning. Until the direct call starts failing you, stay with the simpler path.
The signs you have outgrown it
People rarely decide to build a service of their own. More often they notice they should have had one already. The signs tend to be the same:
- The same rule is written into more than one front end (a website, a mobile app, an internal tool), and the copies have drifted apart.
- Several outside systems have to agree about the same event, and something has to referee. If the payment goes through but the customer record doesn’t save, who puts it right?
- You’re hitting rate limits, meaning the number of requests a provider will accept in a given period, and you need to cache answers or queue work to stay under them.
- Making the direct call work would mean putting credentials into code that runs in the browser.
- A provider wants to send you webhooks, automatic notifications when something happens at their end, and you have no address of your own for them to arrive at.
Any one of these is worth a conversation. Two or three together, and the decision has been made for you.
Anything in the browser can be read
This one settles more arguments than the rest put together. Code that runs in a browser is downloaded to the visitor’s machine, and anyone who opens the developer tools can read what was downloaded.
An API key is a password. If a provider gives you one that has to stay secret, it can’t live in frontend code, however cleverly it’s hidden. It has to sit on a server you control, and that server is a service of your own, however small.
What your own layer buys, and what it costs
What you gain is a single place for the rules. One definition of a valid order, one definition of how a discount applies, one path that every front end goes through. Change a rule once and every screen follows. Swap a provider and you rewrite one adapter, not every screen that touched it.
What you take on is real. Providers go down, so you need retries. You need idempotency, which means that the same request arriving twice, from a double click or a repeated webhook, doesn’t charge a customer twice or create two records. You need monitoring, because when a back end fails without an error anyone sees, nobody knows until a customer complains. And it’s yours to keep running, which is why ongoing development and maintenance belongs in the plan from the start.
None of that is unusual. It’s the everyday work of Node.js and API development, and it’s usually less work than the tangle it replaces. But it isn’t free.
When you do not need one
If one front end calls one provider and your logic amounts to passing data through, integrate directly and spend the time elsewhere. If you run a content website with a form on it, what you have already does the job. And if the rules you’d centralise still change every week, settle them first. A service built around rules that are still moving is only a slower way to change your mind.
Sometimes you need the whole thing at once: interface, logic and data together. Then this is one question inside a larger build, and it belongs under custom web application development.
It’s easier to weigh up in conversation. Tell us which systems are involved and what has to happen between them, and we’ll recommend an approach, including the one where you build nothing new. Describe it on our Get Started page and we’ll reply by email.