The practical Unix API is more than system calls (or POSIX)
What is the 'Unix API'? Some people would be tempted to say that this is straightforward; depending on your perspective it's either the relatively standard set of core Unix system calls or the system calls and library functions required by POSIX. This answer is not wrong at one level, but in practice it is not a useful one.
As people have found out in the past, the real Unix API is the whole
collection of behaviors and environments that Unix programs assume.
It isn't just POSIX library calls; it's also the shell and standard
utilities and files that are in known locations and standard
capabilities and various other things. A 'Unix' without a useful
$HOME environment variable and
/tmp may be specification
compliant (I haven't checked POSIX) but it's not useful, in that
many programs that people want generally won't run on it.
In practice the Unix API is the entire Unix environment. What
constitutes the 'Unix' environment instead of the environment
specific to a particular flavour of Unix is an ever-evolving topic. Once upon a time
mmap() was not
part of the Unix environment (cf); today it
absolutely is. I'm pretty certain that once upon a time the
egrep was effectively Linux specific (as it relied on
egrep being GNU grep); today it's much closer to being part of
Unix, as many Unixes either have GNU grep as
egrep or have added
-o. And so it goes, with the overall Unix API moving
forward through de facto evolution.
Unless you intend for your program to be narrowly and specifically portable to POSIX or an even more minimal standard, it is not a bug for it to rely on portions of the broader, de facto Unix API. It's not even necessarily a bug to rely on APIs that are only there on some Unixes (for example Linux and FreeBSD), although it may limit how widely your program spreads. Even somewhat narrow API choices are not necessarily bugs; you may have decided to be limited in your portability or to at least require some common things to be available.
(The Go build process requires Bash on Unix, for example, although
it doesn't require that
/bin/sh is Bash.)
PS: This is a broader sense of the 'Unix API' (and a different usage) than I used when I wrote about whether the C runtime and library was a legitimate part of the Unix API. The broad Unix API is and always has been layered, and things like Go are deliberately implementing their own API on top of one of the lower layers. In a way, my earlier entry was partly about how separate the layers of the broad Unix API have to be; for example, can you implement a compatible and fully capable Bourne shell using only public Unix kernel APIs, or at most public C library APIs?
(Many people would say that a system where you could not do this was not really 'Unix', even if it complied with POSIX standards.)