Jede Regel ist ein JSON-Objekt.
Alles, was das UI kann, kann die API — die MCP-Tools rufen intern denselben Router auf und können deshalb nie abweichen.
{
"name": "HTML aus Beschreibung entfernen",
"enabled": true,
"definition": {
"if": {
"combinator": "and",
"conditions": [
{ "field": "description", "op": "contains", "value": "<" }
]
},
"then": [
{ "action": "strip_html", "field": "description" }
]
}
}curl -X POST https://app.firefeeds.io/api/v1/rulesets/12/rules \
-H "Authorization: Bearer fft_9c41…" \
-H "Content-Type: application/json" \
-d @rule.jsonBasis /api/v1, Authentifizierung per Bearer-Token.
Tokens werden nur als Hash gespeichert — den Klartext gibt es einmalig beim Anlegen. Ein Token gehört dem Konto, nicht einer Person, und sieht alle Projekte. Fehler kommen als JSON mit passendem Status: 400 Validierung, 401 Auth, 404 nicht gefunden (auch für fremde Projekte).
| Methode | Pfad | Zweck |
|---|---|---|
| GET | /api/v1/projects | Projekte auflisten |
| POST | /api/v1/projects/{id}/sources | Quelle anlegen (xml_url, csv_url, shopware, shopify) |
| PUT | /api/v1/sources/{id}/auto-import | Zeitplan der Quelle: auto_import_times oder auto_import_interval_hours |
| POST | /api/v1/projects/{id}/sources/{sourceID}/runs | Eine einzelne Quelle importieren |
| POST | /api/v1/projects/{id}/category-rules | Google-Kategorie zuordnen — die erste passende Zeile gewinnt |
| POST | /api/v1/rulesets/{setID}/rules | Regel in ein Regelset schreiben |
| POST | /api/v1/rulesets/{setID}/rules/impact | Wirkung einer Regel messen, bevor sie live geht |
| PUT | /api/v1/channels/{id}/rulesets | Regelsets einem Feed zuordnen — Reihenfolge = Anwendung |
| POST | /api/v1/projects/{id}/merchant/sync | Benchmarks, Status und Performance aus dem Merchant Center holen |
| POST | /api/v1/channels/{id}/push | Kanal vom Typ merchant_api jetzt per Merchant API pushen |
| PUT | /api/v1/team/members | Rolle und Projekt-Zuschnitt eines Mitglieds setzen |
| GET | /api/v1/meta/reference | Maschinenlesbare Referenz: Operatoren, Aktionen, Typen, MC-Felder |
| GET | /feeds/{token}.xml | Fertiger Feed — live gerendert, stabile URL |
Die vollständige Referenz — Operatoren, Aktionen, Kanal-Mapping und Feed-Formate — liefert GET /api/v1/meta/reference maschinenlesbar direkt aus der Engine; sie steht außerdem in der Anwendung unter Einstellungen und im Repository unter docs/.
13 Operatoren, 17 Aktionen — streng validiert.
Bedingungen mit und/oder, Aktionen in Reihe; unbekannte Felder lehnt der Server mit 400 ab, statt sie still zu ignorieren. Die Engine ist rein funktional: dieselbe Regel liefert auf demselben Produkt immer dasselbe Ergebnis.
{
"if": {
"conditions": [
{ "field": "price", "op": "lte",
"value_field": "purchase_price_net" }
]
},
"then": [
{ "action": "set_value",
"field": "custom_label_2", "value": "Verlust" }
]
}{
"then": [ {
"action": "shipping_table",
"field": "shipping[1]",
"from": "shipping_weight",
"country": "AT",
"service": "Standard",
"brackets": [
{ "up_to": "0.5", "exclusive": true, "price": "9.52 EUR" },
{ "up_to": "24", "exclusive": true, "price": "24.60 EUR" },
{ "up_to": "32", "price": "67.83 EUR" },
{ "price": "229.67 EUR" }
]
} ]
}Rechts vom Operator steht ein zweites Feld desselben Produkts statt eines festen Werts — Marge, Streichpreis gegen Preis, Bestand gegen Mindestmenge.
Gewichtsstaffel je Zielland als Tabelle; die kleinste passende Obergrenze gewinnt, „bis" und „unter" sind beide möglich. Pauschalen und Freigrenzen bleiben normale Regeln danach.
Versalien-Titel werden lesbar (gemischt Geschriebenes bleibt in Ruhe), die längste von mehreren Beschreibungen gewinnt, Kürzen schneidet an der Wortgrenze.
Mehrere Versand- und Steuerblöcke je Produkt, im XML korrekt verschachtelt, in CSV zur Textfeed-Konvention gefaltet. Ein Block ohne Preis entfällt, statt leer im Feed zu stehen.
Ein Agent, der den ganzen Funktionsumfang steuert.
Anbindung per API-Token in Claude Code oder als Konnektor in claude.ai über den mitgelieferten OAuth-Server. Der empfohlene Ablauf steckt in den Server-Instructions: Referenz lesen, Entwurf mit ff_regel_wirkung am echten Bestand prüfen, erst dann speichern.
claude mcp add --transport http firefeeds \
https://app.firefeeds.io/mcp \
--header "Authorization: Bearer fft_…"| MCP-Tool | Beschreibung | Scope |
|---|---|---|
| ff_referenz | Operatoren, Aktionen, Quellen- und Kanaltypen, MC-Felder — direkt aus der Engine | read |
| ff_projekt_ueberblick | Quellen, Regelsets, Feeds und letzter Lauf eines Projekts in einem Aufruf | read |
| ff_quelle_zeitplan | Automatischen Abruf je Quelle setzen: Uhrzeiten oder Intervall | write |
| ff_import_starten | Import anstoßen, Status über ff_import_status | write |
| ff_regel_generieren | KI-Entwurf einer Regel aus einer Beschreibung — noch nicht gespeichert | read |
| ff_regel_wirkung | Treffer und Vorher/Nachher eines Entwurfs über den ganzen Bestand | read |
| ff_regel_speichern | Regel in ein Regelset schreiben | write |
| ff_feed_qualitaet | Feed gegen die Merchant-Center-Anforderungen prüfen | read |
| ff_api_request | Jeder weitere Endpunkt — Merchant-Center-Sync, API-Push, Team, eigene Felder | api |
Insgesamt 32 Tools für Projekte, Quellen, Produkte, Google-Kategorien, Regeln und Feeds; ff_api_request erreicht jeden übrigen Endpunkt — die Abdeckung wächst mit der API, ohne dass der Server neue Tools braucht.
Konnektor-Anmeldung in claude.ai ohne manuelles Token-Handling.
Die MCP-Tools rufen denselben HTTP-Router auf wie die Oberfläche — eine zweite Implementierung, die auseinanderlaufen könnte, gibt es nicht.
Ein Agent löscht nur Regeln, Regelsets und Kategoriezuordnungen. Feeds (Token!), Quellen (Produkte!) und Zugänge bleiben dem UI vorbehalten — neue DELETE-Routen sind automatisch gesperrt.
Seitenweise nach Postgres — konstanter Speicher auch bei 180.000+ Produkten.
Token holen, Regel schreiben.
Die API ist ab dem Pro-Plan enthalten — inklusive MCP-Server und OAuth-Konnektor.