WordPress API-First Entwicklung: WordPress mit allem verbinden (2026)

Für Unternehmen in Deutschland sitzt auf dem Katalog-Kontrakt ein zweiter Vertrag, den kein Theme abbildet: wer die Rechnung schreibt, wer den Webhook von Payone oder PayPal DE signiert, wo Application Passwords unter der DSGVO liegen. Warteschlangen, Idempotenz und Abstimmung mit dem ERP stehen in der Architektur-Anleitung WooCommerce-ERP-Integration 2026. Hier geht es um den API-Schnitt: URL-Karte, Webhook-Cutover, Fenster der Doppelbuchung, und darum, dass der Shop das Rechnungs-XML nicht erfindet.

Mehr zum Headless-Angebot und zur kommerziellen ERP-Anbindung. Fragen zum Kontrakt: Kontakt.

#1. Was ist API-First WordPress?

Klassische Agenturarbeit startet mit einem Layout in Figma und zieht ein Theme darum. API-First startet mit Custom Post Types, Bestellfeldern und Endpunkten. Das ändert, wer parallel arbeiten kann und welche Felder WordPress überhaupt schreiben darf.

#Der Datenkontrakt

Sie definieren, wie Beiträge, Produkte und Nutzer nach außen aussehen. Dieser Kontrakt ist die Basis. In einem deutschen Shop erklärt er auch, welche Felder WordPress nicht ausstellt: Rechnungsnummer, XRechnung-XML, DATEV-Beraternummer, Leitweg-ID. Diese Werte kommen vom ERP oder von der Kanzlei zurück und liegen als unveränderliches Metadatum an der Bestellung.

Beispiel eines Lese-Kontrakts (Katalog, nicht Beleg):

{
  "endpoint": "/wp-json/v1/products",
  "method": "GET",
  "response": {
    "id": "integer",
    "sku": "string",
    "name": "string (max: 200)",
    "price": "float (2 decimals)",
    "currency": "EUR",
    "tax_class": "enum: standard|reduced|zero",
    "availability": "enum: in_stock|out_of_stock|preorder",
    "warehouse": "string",
    "metadata": {
      "seo_title": "string (max: 60)",
      "seo_description": "string (max: 160)"
    }
  }
}

tax_class darf ein Lager-Bot nicht mitliefern, wenn er nur den Bestand delta’t. Ein PUT auf /wp-json/wc/v3/products/<id> aus JTL-Wawi, der tax_class, Titel und Germanized-Anhang mitnimmt, überschreibt still den reduzierten Satz. Das haben wir an einem Shop gesehen, der nach einem Bestandsjob 19 Prozent auf Bücher schrieb. Der Fehler lag nicht in JTL, er lag im zu breiten REST-Vertrag.

#Backend-Unabhängigkeit

Sobald die API steht, arbeiten Frontend, App und SEO parallel gegen dieselbe Quelle. Ein Team in Köln schreibt das Astro-6-Storefront, ein Team in Berlin die Flutter-App, die Redaktion bleibt in Gutenberg. Ohne Kontrakt wartet das Frontend auf Theme-Tickets. Mit Kontrakt wartet es auf ein JSON-Feld.

• Web-Frontend: Astro 7 oder Next.js liest öffentliche Routen, kein PHP im Browser.
• Mobile App: dieselben Lese-Endpunkte, Auth über Application Password oder OAuth eines Nutzers mit Leserechten, nie über ein WooCommerce-Write-Key im Binary.
• Redaktion: Gutenberg und der klassische Admin bleiben. Headless tötet nicht den Editor.
• Integrationen: CRM, ERP, Zahlungs-Webhooks, DATEV-Export als eigener Takt.

Der Kontrakt trennt Lesen und Schreiben. Ein Headless-Front darf den Katalog cachen. Es darf keine Bestellung auf “bezahlt” setzen, nur weil die Return-URL von PayPal ein Query-String mitgebracht hat.

#2. Eigene REST-API-Endpunkte meistern

Die Standard-REST-API von WordPress deckt Beiträge, Seiten, Medien. Enterprise-Projekte brauchen enge eigene Logik. Die WooCommerce REST API unter /wp-json/wc/v3/ kennt Produkte, Bestellungen, Gutscheine. Bestand aus einem ERP gehört nicht in einen generischen PUT auf das Produkt. Ein Feld zu viel (Preis, Titel, Steuerklasse) wird ohne Fehler überschrieben.

#Geschäftslogik in einer Route bündeln

Statt zehn Requests für Bestellhistorie, Abos und Treuepunkte bauen wir einen Endpunkt wp-json/v1/user-commerce, der ein kompaktes JSON liefert.

add_action('rest_api_init', function () {
    register_rest_route('v1', '/user-commerce/(?P<id>\d+)', [
        'methods'             => 'GET',
        'callback'            => 'get_user_commerce_data',
        'permission_callback' => 'verify_api_token',
        'args'                => [
            'id' => [
                'validate_callback' => static function ($param) {
                    return is_numeric($param);
                },
            ],
        ],
    ]);
});

function get_user_commerce_data($request) {
    $user_id = (int) $request['id'];

    return [
        'orders'        => get_user_orders($user_id),
        'subscriptions' => get_user_subscriptions($user_id),
        'loyalty'       => get_user_loyalty($user_id),
    ];
}

Die App listet Bestellungen ohne PDF-Rechnung und ohne XRechnung-Anhang in jeder Zeile. Das Dokument holt sie on demand beim ERP, wenn der Nutzer die Detailansicht öffnet.

#Eigene REST-Routen für Bestand

Das ERP oder JTL-Wawi ist Quelle der Wahrheit für Lager. WooCommerce wendet nur das Delta an. Eine schmale Route (sku, qty, warehouse, event_id) mit permission_callback an einem WooCommerce-Write-Key, nicht an einem menschlichen Administrator, verhindert, dass ein Redaktions-Token Inventar bewegt.

add_action('rest_api_init', function () {
    register_rest_route('wc-erp/v1', '/stock', [
        'methods'             => 'POST',
        'callback'            => 'wpp_apply_stock_delta',
        'permission_callback' => 'wpp_verify_wc_write_key',
        'args'                => [
            'sku'      => ['required' => true, 'type' => 'string'],
            'qty'      => ['required' => true, 'type' => 'integer'],
            'event_id' => ['required' => true, 'type' => 'string'],
        ],
    ]);
});

event_id ist der Idempotenzschlüssel. Sendet JTL denselben Korrekturjob noch einmal, antwortet die Route mit dem gecachten Ergebnis und zieht nicht erneut ab. Warteschlangen und Sperren stehen in der ERP-Architektur-Anleitung. Hier reicht die Regel: /wc/v3/products/<id> bleibt dem Lager-Bot geschlossen.

#Application Passwords und WooCommerce-Keys trennen

WordPress und WooCommerce authentifizieren zwei Welten. Nicht mischen. Application Passwords hängen am WordPress-Nutzer, liegen gehasht in usermeta und erben dessen Capabilities: Redaktion, Mobile-App, Skript gegen /wp-json/wp/v2/. WooCommerce-REST-Keys (ck_ / cs_) leben in woocommerce_api_keys, mit read, write oder read_write, und authentifizieren /wp-json/wc/v3/. Ein Bestands-ERP bekommt einen write-Key auf Katalog. Ein Headless-Front bekommt read. Nie ein Application Password eines Administrators im App-Binary.

Rotation ist getrennt: ein Woo-Key tauschen loggt die Redaktion nicht aus. Ein Application Password tauschen stoppt nicht den nächtlichen DATEV-Export. Keys nicht in wp_options im Klartext, nicht im Repo der Agentur, nicht in einer .env auf einem All-Inkl-Account, den fünf Freelancer teilen.

#Validierung, Rate-Limits und Hosting

register_rest_route erzwingt Typ, Range, Regex und Sanitizing, bevor der Callback läuft. Jede Schicht sitzt vor der Geschäftslogik:

1. Typ: Integer bleibt Integer.
2. Range: Mengen nicht negativ, SKU-Länge begrenzt.
3. Format: event_id gegen ein festes Muster.
4. Sanitizing: jede Zeichenkette vor der Datenbank.
5. Autorisierung: Token und Capability, nicht “Request kam von intern”.

Rate-Limits (Ausgangspunkt 60 Requests pro Minute und IP, kein Marktpreis) gehören nicht in Transients, sobald mehr als ein PHP-Worker läuft. Auf Hetzner Cloud in Falkenstein oder Nürnberg liegt der Zähler in Redis neben Object-Cache. Transients auf einem Raidboxes-Tarif mit einem Node halten für kleine Katalog-APIs. Sie halten nicht, wenn Payone in einer Spitze 40 Notifications schickt und zwei PHP-FPM-Prozesse denselben Transient lesen.

IP-Adressen der Zahlungs-Notification aus dem Limit nehmen. Ein HTTP 429 an Payone, giropay-Nachfolger im PayPal-Stack oder an PayPal DE lässt die Bestellung bei der Bank bezahlt und in WooCommerce auf “Zahlung ausstehend”.

Hosting ändert, was Sie selbst härten. Raidboxes liefert Managed WordPress, Updates, WAF auf der Box, Backups, Rechenzentrum in Deutschland. Die Plattform wirbt mit ISO 27001 und SOC 2 Type 2 für die Plattform, nicht für Ihren Plugin-Bestand und nicht für eine selbst gebaute REST-Route. Hetzner hat 2026 ein C5-Testat Typ 2 für die IaaS-Schicht veröffentlicht. Nginx, PHP 8.4, Redis und WordPress 7.1 bleiben Ihre Controls. All-Inkl gibt Panel, Mail und TLS. WAF, MFA, Deploy aus Git und getrennte Konten bauen Sie selbst. Eine gemeinsame admin-Kennung im KAS macht jedes Audit-Trail wertlos.

Wer BSI IT-Grundschutz modelliert, legt APP.3.1 auf die PHP-Anwendung (Sessions, REST, Auth) und APP.3.2 auf Nginx oder Apache plus PHP-FPM. C5 auf Hetzner ersetzt APP.3.1 nicht. OPS.1.1.5 verlangt Protokollierung der Schreib-Routen, nicht jeder Katalogansicht. Details und der Scope der Testate stehen im Leitfaden Sicherheitsstandards für Unternehmens-CMS. Kein erfundenes SOC-2-Siegel auf WordPress selbst.

Application Passwords und Woo-Keys sind personenbezogene oder zumindest zugriffsrelevante Geheimnisse. Art. 32 DSGVO (Sicherheit der Verarbeitung) gilt für diesen Speicher. Art. 33 verlangt Meldung an die Aufsicht innerhalb von 72 Stunden, wenn ein Leak Bestellungen und Adressen öffnet. Ein Dump von ck_/cs_ mit read_write auf /wc/v3/orders ist ein solcher Fall. Der BfDI unterscheidet nicht “ist nur ein API-Key” von einem Geheimnis, das Belege trägt.

Zusätzlich:

• CORS eng: nur die Origin des Astro-Frontends und der App.
• TLS: Pflicht. Kein REST über HTTP, auch nicht “nur intern im VPN”.
• Logs: jede Schreib-Route protokollieren. IPs hashen, wenn das Log die EU verlässt.
• Rotation: Application Passwords und Woo-Keys bei Austritt, nicht “wenn jemand dran denkt”.

Payone, giropay-Zahlwege über Payone oder PayPal, und PayPal DE signieren die Server-zu-Server-Notification. Die Browser-Return-URL ist Anzeige, kein Schreibpfad. Signaturvergleich in konstanter Zeit (hash_equals). Ohne gültige Signatur kein Statuswechsel auf “in Bearbeitung”. Der Schlüssel bleibt auf dem Origin, nicht im Cloudflare-Worker, der HTML ausliefert.

#3. WordPress als Content Mesh

Große Organisationen behandeln WordPress 2026 als Knoten in einem Netz, nicht als einzige Wahrheit für Bestand und Beleg.

#Synchronisation mit externen Systemen

WordPress speichert Content. Es spiegelt ihn nicht blind in beide Richtungen. Ein Preisupdate in SAP oder JTL kann die WordPress-API anstoßen, die dann Storefront und App aktualisiert. Der Beleg fließt umgekehrt: der Shop sendet die Kaufabsicht, das ERP nummeriert.

[JTL / SAP] --Bestand--> [WordPress REST wc-erp/v1] --> [Astro 7]
                                                     --> [App]
[Payone / PayPal DE] --HMAC--> [Woo Bestellung]
[ERP-Ack] --dieselbe event_id--> [Bestellung unverändert, wenn schon da]
[nächtlicher DATEV-Export] --Prüfsumme--> [Kanzlei]

Bei einer Shop-Migration (Shopware, Magento, altes WooCommerce auf neues) reduziert sich die API-Arbeit auf drei Stücke:

1. URL-Karte: jede REST-Route und jede Notification-URL von Payone und PayPal hat ein Ziel. Ohne Karte schreibt das Gateway weiter auf den alten Origin, Bestellungen bleiben auf “Zahlung ausstehend”.
2. Webhook-Cutover: Sender pausieren, Queue leeren, neue URLs registrieren. Ein verwaister Webhook während des Schnitts verdoppelt Bestellungen oder verliert Bestand.
3. Fenster der Doppelbuchung: Quelle und Ziel akzeptieren Events für ein begrenztes Intervall mit demselben Idempotenzschlüssel. Dann friert die Quelle ein. DATEV sieht denselben Beleg nicht zweimal, weil der Export hinter der Abstimmung liegt, nicht daneben.

Das ist keine Shopify-Anleitung. Es ist die Karte der Verträge.

#Webhooks und Ereignisse

Hooks benachrichtigen Dritte, wenn ein Beitrag live geht oder ein Nutzer anlegt. Marketing-Webhooks sind eine Klasse. Zahlungs- und ERP-Webhooks sind eine andere.

add_action('transition_post_status', function ($new, $old, $post) {
    if ($new === 'publish' && $old !== 'publish') {
        $payload = [
            'event'     => 'content_published',
            'post_id'   => $post->ID,
            'title'     => $post->post_title,
            'url'       => get_permalink($post->ID),
            'timestamp' => current_time('c'),
        ];

        foreach (get_webhook_subscribers('content_published') as $subscriber) {
            wp_remote_post($subscriber['url'], [
                'body'    => wp_json_encode($payload),
                'headers' => ['Content-Type' => 'application/json'],
                'timeout' => 5,
            ]);
        }
    }
}, 10, 3);

Mautic darf “Kunde hat bezahlt” erst nach HMAC-Prüfung von Payone oder PayPal konsumieren, nicht vom Browser-Return. Ein Lead “Zahlkunde” aus der Thank-you-URL ist der klassische Fehlalarm.

#Event-getrieben statt Punkt-zu-Punkt

Punkt-zu-Punkt (Plugin A ruft Plugin B per HTTP in save_post) zerbricht unter Last. 2026:

• Broker: Redis Streams oder RabbitMQ.
• Async: Events außerhalb des Request-Threads.
• Retry: exponentielles Backoff.
• Dead Letter: nach n Fehlern ablegen und bearbeiten, nicht still verwerfen.

Callbacks von Payone, giropay-Zahlwegen und PayPal DE sind ein zweiter Schreibpfad auf dieselbe Bestellung. Teilen Broker und Gateway nicht denselben Idempotenzschlüssel, stellt das ERP zwei Belege aus oder keinen.

Salesforce oder HubSpot bekommen Leads aus Formularen über ein Application Password mit Leserecht auf das Formular, nicht über einen Woo-write-Key. Dieser Token könnte Bestellungen anlegen. Ein HubSpot-Sync, der nachts Kontakte spiegelt, braucht kein Lagerrecht. JTL oder SAP schreiben Bestand über /wc-erp/v1/stock. Die Bestellung geht nach HMAC ins ERP zur Erfüllung. Die Rechnung liest der Shop vom ERP, er schreibt sie nicht.

#4. Performance der API-Schicht

Die historische Klage gegen die WordPress-API war Latenz. 2026 begegnen wir dem mit Cache in Schichten, und mit der Regel, welche Routen keinen Cache dürfen.

#Object-Cache (Redis)

API-Antworten liegen im Speicher, damit teure SQL-Joins nicht bei jedem Mobile-Hit laufen. Jeder Endpunkt hat eine eigene Strategie nach Volatilität. Zahlungs-Notification und Bestands-Delta cachen wir nicht: ein alter HTTP 200 mit schon geprüfter Signatur darf nicht erneut angewendet werden.

Auf Hetzner liegt Redis neben PHP-FPM. Raidboxes Object-Cache ist Redis unter der Haube, mit den Limits des Tarifs. All-Inkl ohne Redis fällt auf Transients in MySQL zurück. Dann ist “API-First” für einen Katalog mit 8 000 SKUs die falsche Hosting-Wahl, nicht die falsche Architektur.

#Edge-Cache

Cloudflare cached öffentliches JSON am PoP Frankfurt. Ein Produktlisting kommt nicht aus PHP in Falkenstein, wenn der Hit warm ist. Authentisierte Routen, Live-Bestand und Gateway-Callbacks verlassen den Edge und gehen an den Origin.

function add_api_cache_headers($response) {
    if (is_wp_error($response)) {
        return $response;
    }

    $response->header('Cache-Control', 'public, max-age=300, stale-while-revalidate=60');
    $response->header('CDN-Cache-Control', 'max-age=600');

    return $response;
}
add_filter('rest_post_dispatch', 'add_api_cache_headers');

Dieser Filter gilt nicht für wc-erp/v1 und nicht für die Notification-URL von Payone oder PayPal. Cache-Control: public auf einem Zahlungs-Callback ist ein Vorfall, keine Optimierung. Laborwerte unter 20 ms auf einem warmen Redis-Hit am PoP Frankfurt sind erreichbar. Sie sind kein Versprechen für den Checkout-Pfad.

#GraphQL als Lese-Alternative

Für komplexe Leseseiten entfernt WPGraphQL Over-Fetching:

query ProductPage {
  product(id: "123") {
    title
    price
    description
    categories {
      name
      slug
    }
    relatedProducts(first: 3) {
      title
      thumbnail
    }
  }
}

Eine GraphQL-Query ersetzt mehrere REST-GETs. GraphQL ersetzt nicht die schmale Bestands-Route und nicht den Gateway-Webhook. Diese Mutationen bleiben enges REST.

#GoBD, DATEV und XRechnung/ZUGFeRD an der API-Grenze

In Deutschland ist die API-Grenze steuerrechtlich, nicht nur technisch. Die GoBD verlangen für jedes steuerrelevante Verfahren eine Verfahrensdokumentation. Eine bidirektionale Shop-ERP-Kopplung ist ein solches Verfahren. Die Dokumentation beschreibt die Schnittstelle: welche Route schreibt welches Feld, wer der Sender ist, wie lange der Ereignisstrom liegt, wie eine Korrektur als neuer Satz (kein UPDATE auf dem Beleg) gebucht wird. Sie ist kein Plugin. Ein Haken “GoBD-konform” in Germanized oder einem Invoice-Addon ersetzt die Beschreibung nicht. Ein Prüfer liest den Kontrakt, nicht den Plugin-Slug.

Drei GoBD-Folgen für die API, ohne die Queue-Tabelle aus der ERP-Anleitung zu wiederholen:

• Unveränderbarkeit: ein gebuchter Satz wird nicht überschrieben. Storno ist ein neues Event mit eigener event_id.
• Nachvollziehbarkeit: der Stream bleibt liegen, nicht nur der Endzustand in wp_wc_orders.
• Vollständigkeit: eine Dead Letter Queue ist Teil des Belegwesens. Ein Event, das nach Retries dort landet, ist steuerlich nicht verschwunden. Es braucht Verantwortlichen und Frist.

DATEV ist in der Praxis die Übergabe an die Kanzlei, nicht ein zweites Live-ERP. Der Fehler ist, DATEV als weiteren Empfänger derselben REST-Nachricht zu behandeln. Die Übergabe ist ein periodischer Export mit Prüfsumme (ASCII, Rechnungsdatenservice oder Unternehmen online), nachdem Zahlung und ERP-Ack abgeglichen sind. SHA-256 oder der vom Kanzlei-Weg vorgegebene Hash über die Datei, Transfer, Import nur bei Match. Ein Live-Write über /wp-json/wc/v3/orders in DATEV hinein gibt es in diesem Kontrakt nicht. DATEV nimmt Buchungsstapel, keinen PCI-Rohdatenstrom und keinen Redis-Dump.

Der Takt ist kanzleiseitig, oft nächtlich, manchmal zweimal am Werktag. Ein Shop, der nach jedem Payone-Webhook sofort eine DATEV-Zeile schiebt, exportiert Bestellungen, deren ERP-Bestand noch offen ist. Die Kanzlei bucht dann Erlös, den das Lager nicht kennt. Der Hash hängt an der Datei, nicht an der einzelnen REST-Zeile: ändert sich eine Position nach dem Schnitt, entsteht eine neue Datei mit neuem Hash, kein Patch auf den gestern importierten Stapel. SKR03 oder SKR04 und die Steuerschlüssel sind Mapping der Exportschicht, nicht Felder, die WooCommerce REST der Kanzlei live diktiert.

XRechnung und ZUGFeRD sind die ausgehenden Steuerbelege auf Basis von EN 16931. XRechnung (KoSIT, XML) ist im Behördengeschäft Pflicht, ZUGFeRD legt PDF/A plus XML in ein Hybrid. Beide brauchen Felder, die der WooCommerce-Checkout nicht erhebt: Leitweg-ID, Steuerkategorie je Position in maschinenlesbarer Form, Zahlungsbedingungen strukturiert. Der Shop darf dieses XML nicht erfinden. Tut er es (Germanized “XML erzeugen”, ein woocommerce_new_order, das XR-2026-00412 vergibt), wird WordPress zum Rechnungssteller und erbt Unveränderbarkeit, Archiv und Pflichtfelder. Eine Stornierung in WooCommerce löscht keinen bereits ausgestellten Datensatz. Die Korrektur ist ein neuer Beleg im ERP.

Der Shop sendet die Kaufabsicht (Positionen, Steuerklasse, Lieferland, Gateway-Transaktions-ID). Das ERP oder die zertifizierte Fakturierung schreibt XRechnung oder ZUGFeRD und gibt Beleg-ID plus Hash zurück. WordPress speichert das als Metadatum. Anzeige im Kundenkonto ist ein Link auf das Dokument, kein selbst gebautes XML.

Seit der B2B-E-Rechnungspflicht (Start Januar 2025, gestufte Annahme) ist dieser Schnitt keine Kür mehr. Der Checkout erhebt keine Leitweg-ID für eine Behörde in NRW. Er erhebt keine EN-16931-PaymentTerms als strukturierten Block. Wer diese Felder in wp_postmeta nachbildet, damit “der Shop auch XML kann”, pflegt Stammdaten, die der Steuerberater schon im ERP hat, und erzeugt eine zweite Wahrheit. Ein Headless-Front in Astro 7 darf den PDF-Link zeigen. Es darf den XML-Body nicht zusammenbauen.

giropay, Payone und PayPal DE teilen denselben Idempotenzschlüssel mit dem ERP-Ack. giropay als eigenständige Schiene ist in älteren Shops und in Payone-Mandaten noch sichtbar, neu oft über PayPal oder den Payone-Bankweg. Der architektonische Punkt ändert sich nicht: Gateway-Notification und ERP-Bestätigung tragen order_id + gateway_txn_id. Wer zuerst kommt, schreibt. Wer danach kommt, ist ein No-Op. Zwei eigene IDs (Payone-TX plus ERP-Belegnummer ohne gemeinsame Klammer) erzeugen Doppelbelege oder eine bezahlte Bestellung ohne Rechnung.

Im Cutover bleibt dieser Schlüssel. Die URL-Karte verschiebt die Notification auf den neuen Origin. Die Queue wird geleert. DATEV exportiert erst, wenn Quelle und Ziel dasselbe event_id kennen. WooCommerce “reserviert” keine XRechnung-Nummern auf dem alten Shop, um sie auf dem neuen zu beenden. Diese Reservierung bricht die Belegkette.

Kommerzieller Umfang der Anbindung: WooCommerce-ERP-Integration. Queue, Retry, Abstimmung: Architektur-Guide 2026. Der API-First-Satz für Deutschland: die Verfahrensdokumentation beschreibt die Grenze, DATEV kommt als Export mit Hash, XRechnung schreibt das ERP, Gateway und ERP-Ack tragen dieselbe event_id.

#5. Warum WPPoland Ihr API-First Partner ist

Bei WPPoland bauen wir die Schicht, die Kanäle verbindet, ohne den Shop zum Finanzamt zu machen.

1. Individuelle Endpunkte: schmale Bestands- und Commerce-Routen, dokumentiert und getestet. Kein offener PUT auf das ganze Produkt.

2. System-Integrationen: WordPress an ERP (SAP, JTL-Wawi, Navision), CRM (HubSpot, Salesforce) und DATEV-Export. HMAC, Idempotenz, Schreibrichtung wie oben. Leistungsumfang unter WooCommerce-ERP-Integration.

3. Headless-Beratung: ob API-First zum Projekt passt, und der Schnitt. Frontend, wenn nötig, Astro 7 über Headless WordPress.

4. Betrieb: Monitoring der kritischen Routen inklusive Gateway-Callbacks, nicht nur des Startseiten-TTFB.

Preise sind individuell, nach Scope. Keine SKU-Liste in diesem Artikel. Wenn der REST-Kontrakt noch Rechnungsnummern vergibt, schreiben Sie uns.

#6. Fazit: Der Hub des modernen Webs

WordPress 7.1 auf PHP 8.4 ist 2026 ein belastbares Backend, wenn die Routen eng sind. API-First löst das Theme als Gefängnis auf: React-Portal, iOS-App, Kiosk, Storefront in Astro 7 lesen denselben Kontrakt. In Deutschland stellt diese API den Steuerbeleg nicht aus, sie setzt eine Zahlung nicht über ein Query-String, und sie legt Tokens nicht im Klartext auf All-Inkl ab. Payone, giropay-Zahlwege und PayPal DE teilen die Idempotenz mit dem ERP. DATEV kommt nachts mit Prüfsumme. XRechnung und ZUGFeRD kommen vom Rechnungssteller.

Sitzt Ihr Katalog in einem klassischen Theme fest? WPPoland kontaktieren und den Kontrakt öffnen.

Weiterlesen in derselben Locale:

• Architektur WooCommerce-ERP 2026
• WooCommerce-ERP-Integration
• Headless WordPress
• Sicherheitsstandards für Unternehmens-CMS
• WordPress-Entwicklung