日本においては、著作権法第10条第3項において、プログラムのインタフェースやプロトコルが著作物とみなされないことが明確に示されている[26]。
他

互換性のためのAPIを作成するためにそのAPIの実装を解析することは一般的に合法である。この手法は相互運用性のためのリバースエンジニアリングと呼ばれる。
類似する概念

DDI (Device Driver Interface) - デバイスドライバを開発するためのソフトウェアインタフェース。WindowsおよびLinuxの用語。

ファームウェアインタフェース - ファームウェアを開発するためのソフトウェアインタフェース。UEFI[27]など。

ASPI - SCSI 装置を制御するためのソフトウェアインタフェース

特にDDIやファームウェアインタフェースを使う場合は、ソフトウェアがアプリケーションと異なる環境で動作しAPIに依存するライブラリを使用できない場合があるため、開発者は自分が何を使っているか意識する必要がある。
言語束縛とインタフェースジェネレータ

複数の高水準言語での使用を意図したAPIは、文法的・意味的に各言語に適したインタフェースをAPIに自動的にマッピングする機能を提供している。これを言語束縛と呼び、それ自体もAPIである。その目的は、そのAPIに要求される機能のほとんどをカプセル化するため、各言語に薄い層を設けることである。

以下に挙げたものは、コンパイル時に言語とAPIの束縛を行うインタフェースジェネレータである。

SWIG - オープンソースの多言語間のインタフェースジェネレータ（通常はC/C++からスクリプト言語へのインタフェースを生成）

F2PY:[28] - FortranからPythonへのインタフェースジェネレータ

（参考情報）ライブラリー形式の非API

Microsoft Windows、macOS、iOS、AndroidなどのOSには、API以外に、俗に「隠しAPI」や「プライベートAPI」「非公開API」などと呼ばれるライブラリー形式の非APIが存在する。これらの非APIは特定の共通処理をアプリケーション側ではなくシステム内部でのみ再利用することを想定して実装されており[7]、例えばWindowsでは一部の非API関数がシステムDLLにエクスポートされていることから、LoadLibrary 関数を使用して呼び出すことができる。Javaや.NET Frameworkの場合は、カプセル化を破壊することになるが、隠蔽されたメソッドであってもリフレクションを使用して呼び出すことができる。しかし、これらはシステム／サービス提供者が公式に提供している機能ではなくAPIではない。このためこれらの隠し機能を使ったアプリケーションの動作は保証されないし、互換性も将来に渡って保証されることはない。不具合修正があれば容易に変更あるいは破棄される。例えばWindows APIにおいて、timeBeginPeriod(), timeEndPeriod() はアプリケーション開発者向けに正式公開・ドキュメント化されているAPI関数だが、これらは内部でNtSetTimerResolution()を呼び出している[29]。NtSetTimerResolution()は、Windows NT系のシステムDLLのひとつ、ntdll.dllにエクスポートされているが、アプリケーション開発者向けのドキュメントには記載されていない非API関数であり[30]、この非API関数をアプリケーションで直接使用した場合の結果は保証されない。EclipseではPlugin開発にて非APIを使った場合エラーを出す設定がある[31]。Appleが提供するApp StoreではAppleが作成した非APIを使ったアプリケーションは掲載を拒否される[32]。
（参考情報）ライブラリとAPI

APIは関数、プロシージャ、変数やデータ構造といったライブラリによって実装されることが多いが、狭義のAPIではライブラリとAPIは同一ではない。ライブラリ形式ではなくプロトコル形式で提供される場合もあるという理由もあるが、ライブラリ形式である場合も同一視せず区別する必要があるという理由がある。

例えばAPIが関数であればサービスにより提供される関数はAPI関数と呼ぶが、API関数を利用して構築された関数はAPIではないためライブラリ関数と呼ぶ。ライブラリ関数は直接サービスと関係ないか、APIを使って構築されておりサービスを利用する上で必須ではない。逆にAPI関数の存在はサービスを利用する上で必須である。例えばC言語の標準ライブラリ関数であるfwriteは、Windows上ではAPI関数である WriteFile を使って実装されている。WriteFileはOSの機能に直接アクセスできることからfwriteよりも高機能であり、別OSへの移植性を考えなければfwriteの代わりにWriteFileを直接利用してアプリケーションを記述することもできる。同様に、Linuxでは writeシステムコールを利用して実装されている。

APIはサービスを利用するうえで必須になるが、APIを直接使用することは外部サービスに対する依存性を高め移植性を妨げる。