Nope, API compatibility is when you write the code, and ABI compatibility is what happens to already compiled code, but still between app and library. Say you compiled your app against libcurl.so.4 file taken from curl 7.88 packaged by Debian. What happens when, far in the future, you will move your executable file, without recompiling, to a system which has curl 12345.67, but the file will still be libcurl.so.4? It should work fine, that is, the library should export the same symbols (maybe some more added), with more or less the same functionality. Possibly implemented differently, maybe accepting more flags, but the stuff that is there, will be there.
To parent's downvoters: would you kindly cut him some slack? It's OK to ask if you don't know. https://xkcd.com/1053/
Just for a small example how both are not the same, in your C library if you move the positions of a field in a struct it can actually break ABI compatibility (meaning you need to recompile your software), but not API compatibility (meaning you don't need to update your code).
You can also with certain type of APIs increase the size of structs and still be ABI compatible. This is usually done by encoding the size of the type as a member of the struct that is usually assigned via `x.size = sizeof(x)` and passed around as pointers. Takes real care to maintain that though. IIRC this appears somewhat frequently in Win32.
To parent's downvoters: would you kindly cut him some slack? It's OK to ask if you don't know. https://xkcd.com/1053/