Internal APIs

Last Updated Aug 05, 2021

Table of Contents:

What are Internal APIs?

Internal APIs are APIs used by businesses internally to add value, drive productivity, and reduce time spent exchanging information between teams. They exist on the company side of the Line of Business, in what could be considered the "back end" of the company, with no external exposure to customers, and no monetization. They are the usage of APIs purely as tools to make work more efficient.

How can APIs be used internally?

Consider how information flows at a company. One team needs something from another team- say, a table of records. In the old days, an employee would walk over and ask for it. The internet appeared, and the employee could ask for it with an email, or maybe it was stored on an overstuffed company server, but there was still an "ask -> receive" workflow to get information. A server full of company information is a security risk, too.

Internal APIs solve this problem. I can GET the table via API from the server, and the API has authenticated my request, so the server is secure. I can PUT new records with a call. Everything stays up to date and secure, with no extra movement required, and if my company needs, for example, up-to-date exchange rates, I can call that API, too.

Internal APIs show how, despite all the flashy nomenclature and monetization, RESTful APIs are just great tools for solving problems.

The Amazon Moment

There is a famous 2002 Amazon memo where Jeff Bezos moved the company to an internal API model, setting Amazon on its path to cloud dominance. If you weren't around in 2002, well- nobody was thinking this way. Homes still had 56k dial-up modems. This is an interesting historical document, but also shows the principles of internal APIs, and their value as business tools.

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Teams must communicate with each other through these interfaces.
  • There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever.  
  • The only communication allowed is via service interface calls over the network.
  • It doesn't matter what technology they use.
  • All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.


Internal APIs solve internal business problems, and allow them to be automated, scaled, and secure. There are some growing pains in moving to this approach, but the resulting company will be leaner, more agile, and more efficient. Some companies even find they can then externalize their internal solutions to enable customer self-service.

Try Abstract's suite of free API's, trusted by 100,000+ developers.
Get started