An API (application programming interface) is basically a the list of functions or commands that a program responds to. While there is plenty going on "under the hood" of Processing as a program, the API details what is "visible" (or publicly accesible) to the programmer. An external library will also have an API, its own list of new commands that extend the functionality of the programming language.

Processing has an API (all of its methods, variables, etc listed in its reference). Any software that can be manipulated via code has an API. Google released a search engine API, a list of functions that people can put in their code that query Google's search engine. Operating systems have low-level API's at their very basest levels, so that the software running on the operating system can properly communicate with the OS to query or request things like memory, USB ports and other hardware access, networking, etc. But a programming language (usually) takes care of that type of negotiation for you, so when you are writing code, you usually only need the programming language's API.

When you compile the code you've written (in processing, whenever you hit the play button, you are both compiling the code and then executing it), the compiler (which is OS-specific) then converts your written code into machine code, which will likely be informed by the compiler asking for functionality information from the OS (or libraries of the OS). As an example: if I want to draw a 3D cube using openGL, it is just a few lines of code in Processing, and my code will work on any operating system. But once I compile/run it, Processing (which is built upon Java) will use a function of a native (machine-specific) library to find out what exact series of bytes it has to send to my graphics card in order to carry out my command to draw a cube onto the screen.

So there's really no reason for you to worry about OS API's unless you are doing very advanced that cannot be down within the bounds of Processing.