Astro Integrationen: Kann das mit unseren Systemen sprechen?

Ja. Wir bauen den Formular-Endpunkt serverseitig und schreiben über die API direkt einen Datensatz im Zielsystem – mit Ihren Feldern: Quelle, Kampagne, Einwilligungstext, Zeitstempel. Dasselbe Verfahren gilt für HubSpot, Pipedrive, Microsoft Dynamics 365 Business Central oder ein eigenes System. Wichtig ist der Fall, den viele Anbindungen auslassen: Antwortet das Zielsystem gerade nicht, wird die Anfrage zwischengespeichert, erneut versucht und parallel per E-Mail zugestellt. Ein Lead darf nicht verloren gehen, weil eine Schnittstelle kurz stumm war.

Indem die Einwilligung eine technische Bedingung ist und kein Vorhang. Einwilligungspflichtige Werkzeuge stehen nicht fest im Seitenquelltext, sondern werden erst nach der Entscheidung nachgeladen. Vor dem Go-live prüfen wir das im Staging mit offenen Entwicklertools und protokollieren, welche Verbindungen ohne Einwilligung aufgebaut werden – die Antwort soll „keine" lauten. Dieses Protokoll bekommen Sie. Die rechtliche Bewertung Ihrer Verarbeitungen bleibt bei Ihrer Datenschutzberatung; wir liefern die überprüfbare technische Grundlage dafür.

Ein Inventar. Darin steht pro Werkzeug: Zweck, welche Felder übergeben werden, an welchen Anbieter, in welchem Verarbeitungsverfahren, ob eine Einwilligung nötig ist und wer im Haus dafür verantwortlich ist. Für Formulare kommt der konkrete Datenfluss dazu – vom Absenden über unseren Endpunkt bis zum Zielsystem und zur Bestätigungsmail. Erfahrungsgemäß ist dieses Dokument bei Bestandsseiten das erste vollständige Bild, das überhaupt existiert. Es gehört Ihnen, auch wenn Sie später ohne uns weiterarbeiten.

Bei wenigen Rollen und reinem Lesezugriff ist es machbar: Downloads, Preislisten, Partnerdokumente hinter einem Login lösen wir mit On-Demand-Routen und einem Authentifizierungsdienst. Die Grenze ziehen wir früh und deutlich – sobald dahinter Bearbeitungsmasken, Rollenmodelle, Freigaben oder Berechnungen liegen, ist es Individualsoftware und wird auch so kalkuliert. Diese Unterscheidung treffen wir im Erstgespräch, damit Sie nicht im dritten Projektmonat davon überrascht werden.

Nein. Zwei Wege führen dorthin: Entweder die Daten kommen beim Build in die Seite und ein Webhook aus dem ERP stößt den Build an, sobald sich etwas ändert – dann ist die Website wenige Minuten später aktuell, ohne dass jemand etwas tut. Oder die betroffene Route rendert on demand und liest über einen zwischengeschalteten Cache. Wir wählen nach Änderungsfrequenz und danach, wie schlimm eine Verzögerung von Minuten wäre. ERP-Anbindungen sind bei uns bestehende Praxis, siehe IT-Projektleitung.

Für die meisten nicht. Werkzeuge, die über eine bestehende Consent- und Tag-Verwaltung laufen, können Sie selbst aktivieren – wir richten diese Verwaltung so ein, dass neue Einträge dort ihre Kategorie und ihre Einwilligungspflicht mitbringen. Ehrlich gesagt raten wir trotzdem zu einer kurzen Rückfrage vor jedem neuen Skript. Nicht wegen des Aufwands, sondern weil genau so ein Skript-Feld entsteht, das später niemand mehr auflösen möchte. Ein festes JavaScript-Budget hilft dabei mehr als eine Regel.

Beim Ausfall: Daten, die zur Buildzeit in die Seite gekommen sind, bleiben sichtbar – die Website ist nicht von der Verfügbarkeit der Quelle abhängig. Bei Formularen greift die Wiederholungslogik plus E-Mail-Zustellung. Bei eingebetteten Widgets definieren wir vorher, was der Besucher stattdessen sieht, statt einen leeren Kasten zu hinterlassen. Bei Einstellung eines Dienstes: Weil wir jede Anbindung über eine eigene, klar abgegrenzte Schicht führen, ist der Austausch eine begrenzte Arbeit und kein Umbau der Website.

Faustregel: Solange Sie Ihre Produkte an einer Hand abzählen können und es keinen Warenkorb braucht, reicht eine Zahlungsanbindung mit gehosteter Bezahlseite. Tickets, Seminarplätze, Downloads, einzelne Geräte – dafür ist das der schlankere Weg. Sobald Warenkorb, Versandregeln, Steuerlogik, Bestände oder Retouren dazukommen, ist das ein Shopsystem, und wir setzen es hinter die Astro-Website statt es nachzubauen. Die Abwägung im Detail steht unter Astro E-Commerce.

Es kostet etwas, ja – ein fremdes Widget bringt in der Regel eigenes JavaScript mit, auf das wir keinen Einfluss haben. Der Punkt ist, diesen Preis zu begrenzen statt ihn zu bestreiten. Wir kapseln das Widget als Insel und laden es mit client:visible erst, wenn es in den Sichtbereich kommt, oder legen es auf eine eigene Buchungsseite. Wer die Leistungsbeschreibung liest, zahlt dann nichts dafür. Und wir messen vorher und nachher, damit die Entscheidung auf Zahlen steht statt auf Vermutungen.

Die Zahl ist die falsche Frage – entscheidend ist, wie viel davon im Browser landet. Zehn serverseitige Anbindungen kosten den Besucher nichts; ein einziges schwergewichtiges Widget im Seitenkopf kostet ihn spürbar. Deshalb legen wir zum Launch ein JavaScript-Budget fest und messen dagegen. Neue Werkzeuge müssen danach begründet werden oder ein bestehendes ersetzen. Wo eine Seite dieses Budget längst überschritten hat, ist der Einstieg eine Performance-Optimierung statt ein Neubau.

Das entscheiden Sie. Das Repository, die Zugänge und die Dokumentation gehören Ihnen, und alles ist so gebaut, dass ein anderes Team damit weiterarbeiten kann. Wenn Sie es abgeben wollen, übernehmen wir es im Rahmen von Support und Wartung. Ein Punkt, den viele unterschätzen: Schnittstellen altern. Anbieter ändern Felder, kündigen Versionen ab, verschärfen Limits. Jemand muss diese Meldungen lesen – wenn niemand im Haus das tut, sollte es jemand von außen tun.

Ja, nach einem kurzen Audit. Wir sehen uns an, wie das Projekt aufgebaut ist, welche Routen statisch und welche on demand rendern, welcher Adapter gesetzt ist und was bereits eingebunden wurde. Danach sagen wir, was sich sauber ergänzen lässt und was vorher aufgeräumt gehört. Wir übernehmen fremden Code, ohne ihn schlechtzureden – aber wir sagen Ihnen ehrlich, wenn eine Anbindung an einer Stelle sitzt, an der sie beim nächsten Major-Update zum Problem wird.

Ein Paket, das installiert und in der Astro-Konfiguration aktiviert wird und dem Projekt eine Fähigkeit hinzufügt – etwa Unterstützung für ein UI-Framework oder eine Ziel-Laufzeit. Umgangssprachlich meint „Integration" oft auch die Anbindung eines Fremdsystems über dessen API. Beides bauen wir.

Ja, wenn die Verarbeitung bei Ihnen liegen soll. Standardmäßig wird die Website vorgerendert und statisch ausgeliefert. Sobald eine Route Daten entgegennimmt, braucht sie On-Demand-Rendering und damit einen Adapter für die Ziel-Laufzeit – offiziell gepflegt sind unter anderem Node, Vercel und Cloudflare.

Astro ist UI-Framework-agnostisch: Für React, Preact, Svelte, Vue, SolidJS und Alpine.js gibt es offizielle Integrationen. Mehrere lassen sich auf einer Seite kombinieren, solange sie in einer .astro-Datei zusammengeführt werden. Für Integrationen heißt das: Ein vorhandenes Widget-Paket lässt sich meist direkt weiterverwenden.

Ja, und das ist der bevorzugte Weg. Da standardmäßig die gesamte Website vorgerendert wird, landen die Daten fest im HTML. Für Inhalte, die zum Zeitpunkt des Aufrufs stimmen müssen, gibt es Live Collections als dokumentierte Alternative. Mehr dazu unter Astro CMS.

Über einen Webhook. Das CMS meldet die Änderung an einen Build-Hook, der Build läuft, die Seite ist wenige Minuten später aktuell. Dazu gehören Drosselung, damit nicht jeder Tastendruck einen Build auslöst, und eine Benachrichtigung, wenn ein Build fehlschlägt. Details unter Headless CMS anbinden.

Technisch ja – es ist ein Skript wie jedes andere. Die relevante Frage ist die davor: Welche Entscheidung treffen Sie mit diesen Zahlen anders, und rechtfertigt das die Einwilligungspflicht? Wir prüfen zuerst, ob ein serverseitiges oder cookieärmeres Verfahren ausreicht, und binden ein, was diese Prüfung übersteht.

Für kleine geschützte Bereiche ja – über On-Demand-Routen und einen Authentifizierungsdienst. Für alles mit Rollenmodell, Bearbeitungslogik oder Workflows ist ein Anwendungs-Stack die passendere Grundlage. Wo genau die Grenze liegt, steht weiter oben auf dieser Seite unter „Ehrliche Grenzen".