An API (Application Programming Interface) is (according to wikipedia)
[...] a set of routine definitions, protocols, and tools for building software and applications.
An API expresses a software component in terms of its operations, inputs, outputs, and underlying types, defining functionalities that are independent of their respective implementations, which allows definitions and implementations to vary without compromising the interface.
In particular, an API is a convention or a set of definitions, so it is not source code. In other words, an API is mostly a social contract between developers (implementors of some library vs users of that library) documented in some report.
Hence, it makes no sense to speak of source code belonging to (or being in) an API.
Of course, an API is implemented by some source code. In practice, I would expect all the source code of a library implementing an API to be relevant (except perhaps some internal artifact, like specialized code generators used to build the library, or some test suite code).
Some APIs have several ("equivalent") libraries implementing them. A typical example is the POSIX C Standard library (on a Linux system): most Linux systems are using the GNU libc, but some are using the musl-libc, and both GNU libc and musl-libc are implementing the same API (perhaps with extensions peculiar to each library), and you could have a Linux system with both. Likewise, the (large) C++11 standard library has several implementations (most C++11 compilers give there own C++11 standard library).
(so my opinion is that you are confused)
PS. In practice, things are not always that nice. See Joel's Law of Leaky Abstraction and read The Mythical Man-Month