The API is the tip of the topological order of interfaces provided by the platform. For example, .NET would NOT be Windows' API because .NET depends on WIN32 (o

The API is the tip of the topological order of interfaces provided by the platform. For example, .NET would NOT be Windows' API because .NET depends on WIN32 (or even more appropriately, NTDLL) which makes .NET important but non-essential. It doesn't make sense to define "the API" as including all the layers of turtles that wrap the canonical one. Just like we wouldn't say that the UNIX userspace utilities like cp/mv/ls are "THE unix API" because those tools all depend on the system calls. On UNIX the system call interface is THE api for the UNIX operating system, and it IS what people commonly refer to as the C API. It's just a more formal definition of the C API and it is defined by the Open Group. It's abstract and language agnostic because it's provided by well-understood and widely encoded binary interfaces which have been defined to nearly exactly model the abstract so-called C definition. Therefore when we say "C API" we aren't necessarily including things like all the manipulations possible in an implementation intended only for a single language like C, e.g. glibc header files or a thunk that irons out some weird piece of legacy assembly technical debt like 386BSD's affinity for the carry flag. Because unless kernels are willing to implement the same degree of SYSCALL instruction fascism that Microsoft implements with NT then no UNIX vendor really has the right to make that claim that the ordinals they copied from the System V codebase. So people who think that "system Libc" and "system API" are the same thing are generally missing the forest for the trees. Dynamic shared objects are stupid and they aren't systems. A libc is just a tool for interfacing with real system apis.