Strictly speaking, the term API in the literal sense is not a physical artefact - i.e. it's not a source code file, library, binary or service.

The literal form of an API is an agreed set of rules, essentially a 'contract' describing the external surface area or boundary between your own code and whichever service/library/binary your code is using.

Consider the real-world concept of an interface in a banal scenario such as telephone pizza ordering - your API to a pizza restaurant would be the information written on their menu, which describes everything available to order, a telephone number to call, the prices, and information on what to expect such as delivery time or accepted payment methods.

You can pick up any telephone handset and it'll work the same way; furthermore, any member of staff working at the restaurant will be familiar with the menu and will all handle your call in exactly the same way, get you the same pizza delivered in the same amount of time, charge you the same amount of money, etc.

Physically you will be interacting with the telephone handset and verbally you'll be interacting with the staff member, yet neither are part of the pizza restaurant API because those are all interchangable with other handsets and other staff members, who will all operate in the same way by following the API contract (i.e. the same phone number, the same menu information which specifies how to order).

The same underlying principle is essentially considered (in this case) with C libraries -- your vendor has created an implementation as part of their compiler called <math.h>, which is guaranteed to offer exactly what the ISO C standard says it should contain; including things which usually won't be in a vendor's own header file, such as preconditions, postconditions, and the behaviour offered by those functions.

Physically, your code would be using that vendor's implementation, but conceptually the API you are using is formalised in the ISO standard document; your code could use any other vendor's (standard-conforming) implementation and you'll be guaranteed by the ISO standard that it will work in exactly the same way.

Strictly speaking, the term API in the literal sense is not a physical artefact - i.e. it's not a source code file, library, binary or service.

The literal form of an API is an agreed set of rules, essentially a 'contract' describing the external surface area or boundary between your own code and whichever service/library/binary your code is using.

Consider the real-world concept of an interface in a banal scenario such as telephone pizza ordering - your API to a pizza restaurant would be the information written on their menu, which describes everything available to order, a telephone number to call, the prices, and information on what to expect such as delivery time or accepted payment methods.

You can pick up any telephone handset and it'll work the same way; furthermore, any member of staff working at the restaurant will be familiar with the menu and will all handle your call in exactly the same way, get you the same pizza delivered in the same amount of time, charge you the same amount of money, etc.

Physically you will be interacting with the telephone handset and verbally you'll be interacting with the staff member, yet neither are part of the pizza restaurant API because those are all interchangable with other handsets and other staff members, who will all operate in the same way by following the API contract (i.e. the same phone number, the same menu information which specifies how to order).

The same underlying principle is essentially considered (in this case) with C libraries -- your vendor has created an implementation as part of their compiler called <math.h>, which is guaranteed to follow all of the rules in the ISO C standard; the C standard also specifies things which usually won't be in a header file but are part of the API, such as preconditions, postconditions, and the behaviour offered by those functions.

Physically, your code would be using that vendor's implementation, but conceptually the API you are using is formalised in the ISO standard document; your code could use any other vendor's (standard-conforming) implementation and you'll be guaranteed by the ISO standard that it will work in exactly the same way.