I think you’re being confused by the way the term API is being misused and abused by many web developers.

• API means Application Programming Interface, i.e. any officially specified interface between different systems (or parts of the same system).
• Some time ago, it became a big thing for web startup to offer public access to some of their internal data through a web service API, typically using REST and JSON, thus allowing third-party developers to integrate with their systems. Web developers started using the term “API” to mean specifically (and only) “publically accessible web service”, and misusing it to include the implementation thereof.
• In terms of frontend and backend, this web service API (and its implementation) is the backend. Some parts of it may be publically accessible and others only to your frontend.
• A different name for this is “service layer”, i.e. code that
  • represents services which the frontend calls
  • contains no display logic (that’s the job of the frontend, after all)
  • is more abstract and coarse grained than simple CRUD actions (one service call will often involve multiple CRUD actions and should be executed within a database transaction).
  • contains the business logic of the application

Let us sketch out a “typical” website’s architecture, with both a “front-end” and a “back-end”. And since it’s a website, we’ll also explicitly have a “client”. (Since there’s no way for JavaScript in a browser to call MySQL on a server directly.)

For clarity, the terms we’re using are:

• Client: The HTML5 compliant browser, esp. the DOM and the JavaScript there loaded to manipulate it.
• Front-End: The PHP server that the DOM is pointed to, containing both the individual page requested and some AJAX style XML or JSON access points.
• Back-end: A database server, where MySQL runs.

For a properly designed program, each of these components has a private API to communicate with the others. The “front-end” PHP code does not issue arbitrary SQL SELECT statements directly, but rather calls stored procedures, pre-authorized SQL, or even distinct PHP calls to an entirely different instance of PHP that runs on the back-end server. These stored procedures or distinct HTTP calls are themselves an API.

The definition doesn’t change even if we allow for some impurity of our design. If your PHP file writes and sends a SQL string directly to MySQL, IT IS STILL AN API, albeit a very unusual one that you are unlikely to repeat.

Note that it’s entirely possible to have your front-end PHP be strictly synchronous, with no AJAX voodoo whatsoever. If you call the same external PHP functions in said synchronous file, you could consider them as using the same API as the client-side version, although use of the term “API” here may not give any real clarity.

An API as an Application Programming Interface, after all, and really refers to any time one program calls outside of its own process. If you’re writing a project that has both a front-end and a back-end, be those AJAX/PHP/MySQL as above or MS Access/SQL Server, it’s worthwhile to specify explicity how you’ll be calling each other, if for no other reason than to make it easy to know where to look when something breaks.

(And the topic of public API is something else entirely. In our example above, only the URL displayed in the client is a “public API.” Everything else is, in essence, “private.” As in, you don’t expect any code beyond your control to call your internal API, and you either deny such results outright or reserve the right to do so in the future.

Start with the right picture

where does the API come into this picture?

It looks like you need to have the correct diagram in mind to work with:

Breaking it down:

• the front-end view-controller is all about GUI behavior and it’s coded with JavaScript
• the view-controller javascript calls the web-service in a way that conforms to an agreed protocol – the API. This is the entry-point to the back-end.
• the API is the agreed way that the front-end and back-end will work together. This is structurally implied with matching code, and explicitly planned with documentation.
• the web-service ultimately is about data storage and retrieval in the backend database
• (sometimes a web-service might be a gateway to another third-party web-service in turn. EG. PostMark for Emailing)

For completeness:

Does the front-end call the back-end which calls the API?

No. The “Web Service” is the practical thing that is “called”. API is the agreed standard for the names of the URLs, format of data, and purpose of each URL.

Or does the front-end just call the API instead of calling the
back-end?

No. The “API” is not “called”. It’s documented, and both front-end and back-end teams share that information to meet in the middle.

Does the back-end just execute an API and the API returns control to
the back-end (where the back-end acts as the ultimate controller,
delegating tasks)?

No. The back-end is very broad. While the front-end is all contained within a browser, the back-end is everything else often across multiple devices: CDN, Web Server, Application Server, Web Service endpoints, Database, Schema,….

(There are actually two “controllers”: one for the GUI behaviour in the browser, the other is the Application-Server. But more specifically, there are usually many Web-Services hosted in an Application-Server. Each Web-Service is a kind of controller, and the Application-Server routes to the right Web-Service.)

More insight :-

It’s about teams of people

Front-end and Back-end is usually more about the teams and what they do. Front-end people are more like graphic designers, they care about alignment, whitespace, user tasks, colour, fonts, wording, information hierarchy. Back-end people are more like engineers and like to solve technical problems. Both are creative.

Conceptually:

• The frontend is the GUI which needs data
• The backend is everything else: the Data/Schema, Security, Processes, and Infrastructure that runs it all

These underlying concepts help as a guiding light, because in practice, it gets muddled up by prevailing limitations, customs, and best-practice.

Limitations, customs, and current best-practice:

• In practice: A dynamic webpage is half-half. It’s generating HTML (frontend), but getting data to mix in (backend). For a Single Page Application or AJAX application. It is simply front-end.
• Limitation: A Web Browser wants to speak HTTP to get the data.
• Custom: A web-service is used so the web-browser can get data. (This is not doing GUI, so it’s definitely back-end)
• Emerging: GraphQL is a relatively new way so the Web Browser can connect to a single endpoint that can simply expose access to the underlying database more generally.

A REST API handles http requests such as GET, POST, FETCH, DELETE… which can be used depending on your token access to retrieve data in specific format such as json, xml, etc.

This “data” can be used into your own application to get API (Application Programming Interface) which is a public accessible web service to gather data which might be interesting to some audience.

This data might return a set of data representing it failed or retrieve data from it’s API server

API is meant to be back end so it can be used in any front end environment. This means it can be used in a web, android, ios… application that can handle https requests