Ein häufig anzutreffendes Szenario ist eine Internet-Anwendung, die für einen bestimmten Zweck programmiert, und von einer Firma gemietet/gekauft wird, und lokal ausgewertet werden soll – und zwar mit Access. Da die der Web-Anwendung zugrunde liegende Datenbank zwar durch die mietende Firma gepflegt wird, aber nicht im „Besitz“ dieser Firma ist, ist meist eine API (öffentliche Programmierschnittstelle) nötig, über die strukturierte Daten aus dieser Datenbank abgerufen werden können, bzw. auch Daten in die Datenbank eingepflegt werden können.

Im Bild ist die API-Schnittstelle als Schlüsselloch dargestellt, denn eine API verfügt nur über die vom Herausgeber eingestellten, begrenzten, Möglichkeiten der Datenmanipulation. Einsicht in die Tabellenstruktur, Ansicht aller Daten, ist nicht möglich. Eingriffe in die Tabellenstruktur, Hinzufügen oder Entfernen von Tabellen etc., sind nicht möglich.

Die Qualität einer API hängt zudem sehr von ihrer Dokumentation ab.Die für die lokale Access-Anwendung notwendigen Daten können über Requests (Anfragen) an den Server Augenblicks-aktuell geladen werden – oft viele hundert Datensätze.

Sinnvoll ist das dadurch, dass die Arbeit mit der Internet-Anwendung ungestört weiterlaufen kann, und man die Vorteile des Systems nutzt. Daten werden einmal in das System eingegeben, nicht mehrmals und somit nicht redundant. Andererseits sind solche Kaufsysteme natürlich nicht perfekt für einen konkreten Anwendungs-Fall programmiert, und viele Besonderheiten des konkreten Betriebes wären wünschenswert umzusetzen, müssten aber hinzuprogrammiert werden. Das jedoch ist in der Regel für den Hersteller der Webanwendung nicht machbar, bzw. ist für den Anwender nicht bezahlbar.

Hier ist es geraten mit einer leicht gestaltbaren Access-Variante zu agieren. Die Verbindung der flexiblen, lokalen Access-Anwendung mit der „systemfremden“ Internetanwendung (die auf verschiedensten Software-Systemen basieren kann), wird über http-Requests hergestellt.