REST API
api.fabrixa.com
Bestellannahme, Produktkatalog, Kontoverwaltung. Der Endpoint, von dem Ihre Integration bei jeder Bestellung abhängt.
Entwickler · Systemstatus
Live-Status, SLA-Ziele und unser Umgang mit Incidents.
Der Betriebsstatus aller Fabrixa-Dienste: REST API, Webhook-Zustellung, Fabrixa Studio, Produktionslinien in Portugal, Spanien und den Niederlanden sowie Versand. Abonnieren Sie Benachrichtigungen zu Störungen per E-Mail oder Webhook. Die SLA-Ziele, die Reaktionsrichtlinie und die historischen Verfügbarkeitsdaten finden Sie weiter unten.
Überwachte Dienste
Sechs Dienste werden separat erfasst.
Unabhängige Überwachung der Verfügbarkeit pro Dienst. Das Live-Dashboard unter status.fabrixa.com gibt den aktuellen Stand wieder – die untenstehenden Bezeichnungen dienen der Beschreibung und werden auf dieser Seite nicht in Echtzeit angezeigt.
Webhook-Übermittlung
Ausgehende Event-Übermittlung
Ausgehender Webhook-Fan-out: order.created / order.updated, Retry-Queue, HMAC-Signatur. Skaliert unabhängig von der eingehenden API.
Fabrixa Studio
studio.fabrixa.com
Einbettbarer Produktkonfigurator (iframe): gespeicherte Konfigurationen und Vorschau-Darstellung. Als White-Label-Lösung in Ihren Endkunden-Shops.
Produktionsstandorte
PT · ES · NL
Kapazität der Drucklinien in Portugal, Spanien und den Niederlanden. Wird bei Rückstau in der Warteschlange als „degraded“ ausgewiesen – kein binärer „Up/Down“-Wert.
Versand
Übergabe an den Carrier
Vergabe von Sendungsverfolgungsnummern und Übergabe an den Spediteur. Von unseren Versandpartnern übermittelte, spediteurspezifische Statusinformationen.
Dashboard
account.fabrixa.com
Konto-Dashboard für Schlüssel, Abrechnung, Prüfprotokolle und manuelle Bestellannahme. Dient als Sekundärsystem zur API für den Produktionsdatenverkehr.
SLA-Ziele
Wozu wir uns öffentlich verpflichten.
Öffentliche Zielvorgaben für die Standardstufe. Für Unternehmenskunden werden höhere SLAs in ihrem MSA festgeschrieben – sprechen Sie mit unserem Team. Wir überprüfen monatlich die Einhaltung dieser Zielvorgaben und veröffentlichen die tatsächliche Verfügbarkeit.
99.9%
Monatliches Verfügbarkeitsziel für REST API und die Webhook-Übermittlung.
<400 ms
p95-Reaktionszeit am Endpoint zur Bestellerstellung, gemessen aus Regionen der EU.
99.5%
Erfolgreiche Übermittlung von Ereignissen im Bestell-Lebenszyklus innerhalb von 60 Sekunden nach dem Statuswechsel. Bis zu 10 Retries, bevor der Endpoint deaktiviert wird.
Reaktion auf Vorfälle
Wie wir mit Ausfällen umgehen.
Öffentliche Meldung von Vorfällen auf dem Live-Dashboard. Abonnenten erhalten innerhalb von fünf Minuten nach Meldung eines Vorfalls Benachrichtigungen per E-Mail oder Webhook, während des Vorfalls alle 30 Minuten Aktualisierungen sowie innerhalb von fünf Werktagen nach der Behebung eine Nachbetrachtung.
01
Erkennung
Die interne Überwachung benachrichtigt die Technikabteilung innerhalb von Sekunden, sobald eine Leistungsminderung festgestellt wird. Der Status des öffentlichen Dashboards wechselt innerhalb von fünf Minuten nach Bestätigung eines Vorfalls auf „investigating“.
02
Kommunikation
Abonnierte Kunden werden über ihren bevorzugten Kanal – E-Mail oder Webhook – während des Vorfallszeitraums mindestens alle 30 Minuten über den aktuellen Stand informiert.
03
Lösung + Nachbetrachtung
Der Status der Fehlerbehebung wird in Echtzeit veröffentlicht. Innerhalb von fünf Werktagen folgt eine öffentliche Nachbetrachtung: Was ist passiert, was war die Ursache und welche Maßnahmen ergreifen wir, um eine Wiederholung zu verhindern.
Abonnieren
Drei Möglichkeiten, benachrichtigt zu werden.
E-Mail
Für Aliase des Ops-/Eng-Teams
Einen Team-Alias abonnieren (z. B. ops@yourcompany.com) zu Incident-Benachrichtigungen. Filtern Sie nach Dienst, wenn Sie sich nur für bestimmte Teilsysteme interessieren.
Webhook
Für automatisches Alerting
Empfangen Sie Vorfallmeldungen als JSON-POST an Ihr Vorfallmanagementsystem. Leiten Sie diese über einen eingehenden Webhook direkt an PagerDuty, Opsgenie oder Slack weiter.
RSS / Atom
Für Dashboard-Widgets
Ein RSS-Feed mit allen Vorfällen und Aktualisierungen – praktisch zum Einbinden in interne Status-Dashboards oder zum Zusammenführen mit anderen Feeds zum Lieferantenstatus.
Geplante Wartungsarbeiten
Ankündigungsfristen für geplante Arbeiten.
Wartungsfenster werden mindestens sieben Tage im Voraus angekündigt. In der Regel handelt es sich um rollierende Wartungsarbeiten ohne Ausfallzeiten; Wartungsarbeiten mit erheblichen Auswirkungen sind selten, werden in Zeiten mit geringem Datenverkehr geplant und 14 Tage im Voraus angekündigt.
Rolling / ohne Betriebsunterbrechung
Die meisten Upgrades und Infrastrukturänderungen werden ohne Ausfallzeiten durchgeführt – rollierende Neustarts, Blue-Green-Datenbankwechsel, schrittweise Einführung. Dies wird auf der Statusseite als Information bekannt gegeben; seitens der Kunden sind keine Maßnahmen erforderlich.
Wartungsmaßnahmen mit großer Wirkung
Selten; nur bei größeren Migrationen oder einschneidenden Infrastrukturänderungen vorgesehen. Wird 14 Tage im Voraus per E-Mail, Webhook und Statusbanner angekündigt. Geplant für Sonntag, 03:00–05:00 Uhr MEZ, mit einem voraussichtlichen Ausfallzeitfenster von maximal zwei Stunden.
Unternehmens-SLA
Höhere Ziele, die in der MSA festgeschrieben sind.
Die oben genannten Standardziele sind öffentliche Verpflichtungen. Unternehmenskunden – mit einem Bedarf von mehr als 10.000 Einheiten pro Monat, Hotelgruppen mit mehreren Standorten oder Plattformintegrationen – erhalten höhere SLAs, die im Rahmenvertrag (Master Supply Agreement) festgeschrieben sind, sowie dedizierte Eskalationswege für Störfälle, reservierte Produktionskapazitäten und einen namentlich benannten technischen Kundenbetreuer. Sprechen Sie mit unserem Team über die SLA-Bedingungen für Unternehmenskunden, Optionen für dedizierte Kapazitäten und die MSA-Vorlage.
Erst Status, dann Debuggen
Live-Status: status.fabrixa.com
Gibt es bei Ihrer Integration irgendwelche Unregelmäßigkeiten? Schauen Sie zunächst im Live-Status-Dashboard nach, bevor Sie ein Support-Ticket eröffnen – die meisten kurzzeitigen Störungen beheben sich von selbst, noch bevor das Ticket bearbeitet wird.