Die API muss alle Funktionen abdecken, die vom Original-WebOPAC angeboten werden. Dabei ist es akzeptabel, wenn eine Funktion für den Endnutzer intern über mehr als einen API-Aufruf realisiert wird oder ein API-Aufruf anhand von Aufruf-Parametern verschiedene Endnutzer-Funktionen bereitstellt – soweit die API damit nicht einen für den Endnutzer umständlicheren Workflow erzwingt. Batch-Aufrufe – etwa die Abfrage von Ausleihstati für mehrere Titel – sind wünschenswert.
Die API sollte alle Aufruf-Parameter jeweils auf ihre Gültigkeit hin prüfen und präzise Fehlermeldungen in Form von Codes zurückliefern. Allgemein sollten Informationen immer Codes und nicht über – von der Bibliothek abhängige und jederzeit änderbare – Freitext-Angaben transportiert werden. Soweit praktikabel sollten die Codes in verschiedenen System-Installationen identisch verwendet werden. Die ergänzende Klartext-Ausgabe – evtl. sogar in einer durch einen Anfrage-Parameter beeinflussbaren Sprache – stellt einen wünschenswerten Mehrwert dar.
Es ist nicht akzeptabel, wenn für die Konstruktion valider API-Aufrufe Wissen über die System-Konfiguration außerhalb des Bibliothekssystems selbst vorgehalten (und damit dupliziert) werden muss.
Sofern Wissen über die System-Konfiguration benötigt wird, muss diese Information in strukturierter Form über ergänzende API-Aufrufe ausgelesen werden können.
System-Logik und Stati müssen innerhalb der API gekapselt sein, damit ein API-Client nicht die in der Software verborgenen Algorithmen nachbauen muss. Beispielsweise muss bei der Abfrage des Ausleihstatus eines Exemplars die Information, ob ein bestimmter Titel in einer bestimmten Zweigstelle von einem bestimmten Nutzer bestellbar ist, im System getroffen und von der API-Antwort übermittelt werden.
API-Aufrufe – Aufrufparameter, Antwort-Formate, verwendete Codes und zulässige Werte etc. – müssen dokumentiert sein. Bei Versions-Änderungen ist ein Changelog erforderlich.
Die API muss eine ausreichende Performanz aufweisen, um inklusive eines darüber aufgebauten Frontends die Antwortzeiten des System-eigenen WebOPACs einhalten oder theoretisch sogar unterbieten zu können. Der Zugriff sollte mit aktuell als modern und zukunftsfähig eingeschätzten Mitteln erfolgen, d.h. möglichst auf dem HTTP(S)-Protokoll beruhen, REST-konform oder REST-ähnlich strukturiert sein und Daten in XML oder JSON serialisieren. Soweit möglich sollten Client-Zugriffe "Stateless" möglich sein. Der Einsatz einer standardisierten API/Protokoll-Kombination ist grundsätzlich zu bevorzugen, soweit dieses nicht technisch veraltet ist.
Die vorstehende Beschreibung definiert die bestehenden Anforderungen notwendigerweise sehr abstrakt. Detail-Abweichungen in der konkreten Umsetzung können akzeptabel sein – eine definitive Aussage dazu ist jedoch erst im Rahmen einer Prüfung der jeweiligen API möglich.