n8n mit ameax verbinden: Token, Abfragen, Fehler

Der erste n8n-Workflow gegen eine neue Schnittstelle scheitert selten an der großen Idee, sondern an Kleinigkeiten: Das Token steht im falschen Header, der Body kommt als Formular statt als JSON an, der Filter kennt keinen Operator, und nach 25 Kunden ist Schluss, weil niemand geblättert hat. Diese Anleitung räumt diese Kleinigkeiten einmal gründlich aus dem Weg.

n8n ist ein Werkzeug eines anderen Herstellers, in dem Sie Abläufe aus Knoten zusammensetzen: ein Auslöser, dann Abfragen, Verzweigungen, Aufrufe anderer Dienste. Sie richten in ameax einen Zugang für n8n ein, hinterlegen die Zugangsdaten in n8n, bauen die ersten Aufrufe mit dem HTTP-Request-Knoten, fragen neue und geänderte Datensätze zuverlässig ab, werten Fehler aus und geben einem Sprachmodell die OpenAPI-Beschreibung Ihrer Installation als Werkzeugkatalog. Alle weiteren Szenarien im Bereich Automatisierung bauen auf diesen Grundlagen auf.

Der Ablauf im Überblick

Die Anbindung besteht aus wenigen Schritten, die Sie einmal einrichten und dann in jedem Workflow wiederverwenden. ameax bleibt dabei das führende System, n8n ist der Taktgeber, ein Sprachmodell bearbeitet Inhalte, und wo eine Entscheidung nicht eindeutig ist, prüft ein Mensch.

1. Technischen Benutzer anlegen. In ameax ein eigener Benutzer für den Workflow, mit genau den Rechten, die der Ablauf braucht.
2. API-Token erzeugen. Unter /c/apitoken ein Token für diesen Benutzer, mit Ablaufdatum und, wenn möglich, IP-Beschränkung.
3. Zugangsdaten in n8n hinterlegen. Als Credential vom Typ Header Auth oder Basic Auth, damit das Token nicht in jedem Knoten steht.
4. Erste Aufrufe bauen. Mit dem HTTP-Request-Knoten einen Kunden suchen und eine Aktivität anlegen.
5. Blättern und zeitgesteuert abfragen. Listen vollständig lesen und neue oder geänderte Datensätze seit dem letzten Lauf finden.
6. Fehler auswerten. Statuscodes, Fehlerliste und X-Request-Id nutzen, statt den Workflow einfach abbrechen zu lassen.
7. Sprachmodell anbinden. Die OpenAPI-Spezifikation Ihrer Installation als Werkzeugbeschreibung für einen KI-Agenten verwenden.
8. Optional: Webhook-Posteingang beschicken. Unstrukturierte Texte an ameax übergeben und dort per KI zuordnen lassen.

Vorbereitung in ameax

API freischalten

Die REST-API v2 ist im Paket Plus des AkquiseManager CRM als „API / offene Schnittstelle" enthalten und wird für Ihre Installation freigeschaltet. Sie ist unter https://ihrefirma.ameax.de/api/v2/ erreichbar, gleichwertig auch unter /api/rest/2.0/. Aufrufe über unverschlüsseltes HTTP werden abgelehnt.

Technischen Benutzer anlegen

Ein API-Token gehört immer zu einem Benutzer und erbt dessen Rechte. Eigene Rechte-Bereiche je Token gibt es nicht. Wenn Sie ein Token an Ihr persönliches Konto hängen, kann der Workflow alles, was Sie können, und jede Aktivität, die er ohne ausdrückliche Angabe anlegt, erscheint unter Ihrem Namen. Legen Sie deshalb einen eigenen Benutzer an, etwa „n8n Leadeingang", und geben Sie ihm über seine Benutzergruppe nur die Rechte, die der Workflow braucht. Für mehrere Workflows mit sehr unterschiedlichen Aufgaben lohnen sich mehrere technische Benutzer.

Token erzeugen

Unter /c/apitoken erzeugen Sie für diesen Benutzer ein Token. Zwei Einstellungen sollten Sie nutzen:

• Ablaufdatum. Abgelaufene Token werden beim nächsten Zugriff deaktiviert. Ein Ablaufdatum erzwingt, dass Zugänge regelmäßig überprüft werden. Tragen Sie das Datum in Ihren Betriebskalender ein, damit der Workflow nicht unbemerkt stehen bleibt.
• IP-Beschränkung. Läuft Ihr n8n unter festen Adressen, hinterlegen Sie diese am Token. Zusätzlich gibt es eine systemweite IP-Freigabeliste, die auch CIDR-Bereiche kennt.

Nach wiederholten Fehlversuchen sperrt ameax mit Status 429. Ein falsch hinterlegtes Token fällt deshalb schnell auf; testen Sie es zuerst mit einem einzelnen Aufruf, bevor Sie einen Workflow in einer Schleife laufen lassen.

IDs nachsehen und notieren

Aktivitätsarten, Ergebnisse und Verkaufsphasen lassen sich über die API nicht auflisten. Sehen Sie die IDs, die Ihre Workflows brauchen, einmalig in den Einstellungen von ameax nach. Status von Verkaufschancen sind ebenfalls IDs; in der Standardeinrichtung steht 14 für aktiv, 15 für gewonnen und 16 für verloren. Kampagnen, Kampagnenstatus und Vorgangs-Schemas dagegen können Sie über /api/v2/projects, /api/v2/project-types und /api/v2/task-schemes abfragen. Legen Sie außerdem eine eigene Aktivitätsart für Einträge an, die ein Workflow schreibt, zum Beispiel „Automatisierung" oder „KI-Auswertung".

Optional: Posteingang und Webhook-Token

Wenn Sie unstrukturierte Texte über den Webhook-Posteingang verarbeiten lassen wollen, richten Sie in ameax einen Posteingang ein und legen dort fest, welche KI-Aktion folgt: keine, Kunde anlegen oder aktualisieren, oder Ansprechpartner zu einem erkannten Kunden ergänzen. Dazu gehört ein Webhook-Token, das Sie für eine Maschine wie n8n fest an diesen Posteingang binden können.

Auslöser

Ein Workflow startet auf einem von drei Wegen, und die Wahl hängt davon ab, woher der Anlass kommt:

• Zeitgesteuert in n8n. Ein Schedule Trigger startet den Workflow in einem festen Takt, der dann über die API abfragt, was sich seit dem letzten Lauf geändert hat. Das ist der richtige Weg, wenn der Anlass in ameax entsteht, etwa eine neue Verkaufschance oder ein neues Ticket.
• Durch das externe System. Ein Webformular, ein Voice-Agent-Dienst oder ein Postfach schickt seine Daten an einen Webhook-Knoten in n8n. Der Workflow startet sofort und schreibt das Ergebnis nach ameax.
• Über den Webhook-Posteingang von ameax. n8n oder ein anderes System übergibt Rohtext an ameax, und die Zuordnung zu Kunde und Person passiert in ameax selbst, mit Prüfstatus für unklare Fälle.

Für zeitgesteuerte Workflows ist ein Takt von einigen Minuten für die meisten Vertriebsabläufe ausreichend. Wie Sie dabei keine Änderung verpassen, beschreibt der Abschnitt zum zeitgesteuerten Abfragen weiter unten.

Umsetzung Schritt für Schritt

Zehn Schritte, aber sie sind kein Workflow, sondern eine Reihenfolge zum Lernen. Schritt 1 richtet die Zugangsdaten ein. Die Schritte 2 bis 5 sind die vier Handgriffe, aus denen danach jeder Workflow besteht: lesen, schreiben, ändern, blättern. Die Schritte 6 und 7 entscheiden, ob er im Betrieb besteht — Änderungen zuverlässig abholen und Fehler auswerten. Danach können Sie bauen. Die Schritte 8 bis 10 sind drei Zugaben, die nichts miteinander zu tun haben: Prozess-Buttons auslösen, einem Sprachmodell die Schnittstelle beschreiben, Rohtext von ameax selbst zuordnen lassen.

1. Credentials in n8n anlegen

ameax akzeptiert das Token auf zwei Arten. Beide funktionieren gleich; wählen Sie die, die Ihnen in n8n besser passt.

• Header Auth: Name Authorization, Wert Bearer IHR_TOKEN.
• Basic Auth: Benutzer api, Passwort ist das Token.

Im HTTP-Request-Knoten wählen Sie dann unter Authentication „Generic Credential Type" und die angelegte Credential. So steht das Token an einer Stelle und lässt sich beim Ablauf austauschen, ohne jeden Knoten anzufassen.

2. Erster Test: einen Kunden suchen

Der einfachste Aufruf ist eine Suche nach E-Mail-Adresse. Im HTTP-Request-Knoten: Methode GET, URL https://ihrefirma.ameax.de/api/v2/customers, und als Query-Parameter filter[email] mit dem gesuchten Wert.

GET https://ihrefirma.ameax.de/api/v2/customers?filter[email]=einkauf@muster-gmbh.de
Authorization: Bearer IHR_TOKEN

Die Antwort ist eine Liste in einer festen Hülle, auch wenn es nur einen oder keinen Treffer gibt:

{
  "data": [
    {
      "id": 4711,
      "name": "Muster GmbH",
      "email": "einkauf@muster-gmbh.de",
      "city": "Koblenz",
      "agent_id": 3,
      "updated_at": "2026-09-27 16:02:11",
      ...
    }
  ],
  "total": 1,
  "page": 1,
  "per_page": 25
}

In n8n prüfen Sie danach mit einem IF-Knoten, ob total größer als 0 ist. Filter sind reine Gleichheitsfilter, ein Stern dient als Platzhalter: filter[email]=*@muster-gmbh.de findet alle Adressen der Domain. Mehrere Filter werden mit UND verknüpft. Eine Suche nach Telefonnummer gibt es nicht. Für externe IDs stehen filter[external_id] am Kunden und die Kundenkennungen unter /api/v2/customer-identifiers bereit, dort mit filter[type] und filter[identifier].

3. Eine Aktivität anlegen

Für schreibende Aufrufe stellen Sie im HTTP-Request-Knoten die Methode auf POST, den Body auf JSON und achten darauf, dass der Header Content-Type: application/json gesendet wird. Ein Body als Formular wird nicht angenommen. Die IDs im Beispiel sind Beispielwerte.

POST https://ihrefirma.ameax.de/api/v2/actions
Authorization: Bearer IHR_TOKEN
Content-Type: application/json

{
  "customer_id": 4711,
  "activity_id": 12,
  "date": "2026-09-28 14:30:00",
  "subject": "Anfrage über Webformular eingegangen",
  "notice": "Bewertung (KI): passt zur Zielgruppe. Begründung: ..."
}

Pflicht sind customer_id, subject (höchstens 250 Zeichen) und date. Optional sind unter anderem person_id, user_id, project_id für die Kampagne, sale_id für die Verkaufschance, activity_id für die Aktivitätsart und finding_id für das Ergebnis. Ohne user_id gilt der API-Benutzer als Verfasser. Die Antwort hat Status 201, einen Location-Header und enthält den angelegten Datensatz mit seiner id.

Für das Datum in n8n bietet sich ein Ausdruck an, der den aktuellen Zeitpunkt im Format JJJJ-MM-TT HH:MM:SS erzeugt, etwa mit $now.toFormat('yyyy-MM-dd HH:mm:ss').

4. Ändern mit PATCH, nicht mit dem ganzen Datensatz

Ein naheliegendes Muster ist: Datensatz lesen, ein Feld ändern, alles zurückschicken. Das scheitert, weil die Antwort nur lesbare Felder wie id, created_at oder updated_at enthält. Schickt man sie zurück, antwortet die API mit 422 und dem Fehlercode read_only. Schicken Sie mit PATCH nur die Felder, die sich ändern sollen:

PATCH https://ihrefirma.ameax.de/api/v2/sales/3301
Content-Type: application/json

{
  "sellingstatus": 9,
  "probability": 60
}

Die 9 steht in der Standardeinrichtung für die Phase „Angebot"; prüfen Sie die IDs in Ihrer Installation. Beim Anlegen einer Verkaufschance setzen Sie den Status immer ausdrücklich, zum Beispiel "salestatus": 14 für aktiv (Standard-ID). Bei Textvorlagen gilt eine Ausnahme: Sie werden nur mit PUT vollständig ersetzt, ein PATCH gibt es dort nicht.

5. Blättern

Listen liefern standardmäßig 25 Einträge je Seite, höchstens 100 über per_page=100. Das Feld total nennt die Gesamtzahl. Um alle Einträge zu lesen, erhöhen Sie page, bis page × per_page mindestens total erreicht oder eine Seite leer zurückkommt. Im HTTP-Request-Knoten von n8n lässt sich das über die eingebaute Paginierung abbilden: Parameter page mit dem Ausdruck für die Seitennummer erhöhen und als Abbruchbedingung eine leere data-Liste setzen. Alternativ bauen Sie eine Schleife aus HTTP-Request- und IF-Knoten.

GET https://ihrefirma.ameax.de/api/v2/customers?filter[agent_id]=3&per_page=100&page=2

Mit fields[customer]=id,name,email begrenzen Sie die Antwort auf die Felder, die der Workflow wirklich braucht. Das hält die Datenmengen klein und ist zugleich der erste Schritt zu einem sparsamen Prompt.

6. Neue und geänderte Datensätze zeitgesteuert abfragen

Einen Filter „geändert seit" und Vergleichsoperatoren wie „größer als" gibt es nicht. Das Muster lautet deshalb: absteigend nach Änderungszeitpunkt sortieren, blättern, bis ältere Einträge kommen, und den letzten Stand speichern.

1. Schedule Trigger startet den Workflow, zum Beispiel alle zehn Minuten.
2. HTTP Request ruft GET /api/v2/sales?sort=-updated_at&per_page=100&page=1 ab. Sortieren nach updated_at geht bei Kunden, Ansprechpartnern, Aktivitäten, Verkaufschancen und Vorgängen.
3. Code-Knoten vergleicht jeden Eintrag mit dem gespeicherten Zeitstempel und gibt nur neuere weiter.
4. Weitere Seite nur dann, wenn alle Einträge der aktuellen Seite noch neuer waren als der gespeicherte Stand.
5. Zeitstempel speichern: Der jüngste gesehene updated_at wird für den nächsten Lauf gemerkt.

Zum Speichern eignen sich die Static Data des Workflows. Ein Code-Knoten könnte so aussehen:

// Code-Knoten "Neue Einträge auswählen" (Mode: Run Once for All Items)
const state = $getWorkflowStaticData('global');
const since = state.lastUpdatedAt || '2026-09-01 00:00:00';

const rows = $input.first().json.data;
const fresh = rows.filter(r => r.updated_at > since);

if (fresh.length > 0) {
  // Liste ist absteigend sortiert: der erste Eintrag ist der jüngste
  state.nextUpdatedAt = fresh[0].updated_at;
}

return fresh.map(r => ({ json: r }));

Zeitstempel kommen als Zeichenkette im Format 2026-09-27 16:02:11 und lassen sich deshalb direkt als Text vergleichen. Übernehmen Sie nextUpdatedAt erst am Ende eines erfolgreichen Laufs nach lastUpdatedAt; bricht der Lauf ab, werden dieselben Einträge beim nächsten Mal erneut verarbeitet, statt verloren zu gehen. Beachten Sie, dass n8n Static Data nur bei aktiven, produktiv laufenden Workflows dauerhaft speichert, nicht bei manuellen Testläufen. Wer den Stand lieber sichtbar hält, legt ihn in einer eigenen Datenablage ab.

Zwei Feinheiten verhindern doppelte Arbeit. Erstens können mehrere Einträge denselben Zeitstempel tragen; ein strenger Vergleich mit „größer als" überspringt dann im Grenzfall einen Eintrag, der in derselben Sekunde gespeichert wurde. Wer das ausschließen will, vergleicht mit „größer oder gleich" und merkt sich zusätzlich die IDs der Einträge mit dem letzten Zeitstempel. Zweitens ändert der Workflow selbst Datensätze. Solche Einträge erkennen Sie am Feld updated_by, das die ID des Benutzers enthält, der zuletzt geändert hat. Ist das der technische Benutzer des Workflows, wird der Eintrag übersprungen.

7. Fehler auswerten

Fehler kommen als application/problem+json nach RFC 7807. Stellen Sie im HTTP-Request-Knoten ein, dass auch Fehlerantworten mit Statuscode und Headern weitergegeben werden, oder nutzen Sie die Fehlerausgabe des Knotens, damit ein nachfolgender Knoten sie auswerten kann.

Eine Validierungsantwort sieht so aus:

{
  "type": "about:blank",
  "title": "Validation Error",
  "status": 422,
  "detail": "The submitted data could not be validated",
  "request_id": "...",
  "errors": [
    { "field": "subject", "code": "max_length", "message": "..." }
  ]
}

Jede Antwort trägt den Header X-Request-Id. Schreiben Sie ihn bei Fehlern in Ihr Protokoll; damit lässt sich ein einzelner Aufruf im Gespräch mit dem Support eindeutig benennen. Die Option „Retry On Fail" des Knotens ist sinnvoll für Serverfehler und Zeitüberschreitungen, aber nicht für 4xx-Fehler: Die schlagen beim zweiten Versuch genauso fehl.

Weil die API keine Idempotenz-Schlüssel kennt, stellt der Workflow die Wiederholbarkeit selbst her. Vor jedem Anlegen wird gesucht; wer nach einer Zeitüberschreitung unsicher ist, ob ein Datensatz angelegt wurde, sucht erst per external_id oder Kundenkennung und legt nur an, wenn nichts gefunden wird.

8. Prozess-Buttons auslösen

Prozess-Buttons führen hinterlegte Abläufe in ameax aus, etwa Aktivität plus Wiedervorlage plus Statuswechsel. Die verfügbaren Buttons eines Kunden liefert GET /api/v2/customers/{id}/proceedings, ausgelöst wird mit:

POST https://ihrefirma.ameax.de/api/v2/customers/4711/proceedings/7/execute
Content-Type: application/json

{ "person_id": 802 }

Wichtig: Die Antwort hat Status 200, auch wenn der Ablauf nicht ausgeführt werden konnte. Maßgeblich ist data.attributes.success, dazu erklärt message den Grund. Prüfen Sie dieses Feld in einem IF-Knoten, bevor der Workflow weitermacht.

9. OpenAPI als Werkzeugbeschreibung für ein Sprachmodell

Unter GET /api/v2/openapi.json (oder .yaml) liefert Ihre Installation die vollständige Beschreibung aller Endpunkte, mit Token geschützt. Sie ist mandantenspezifisch und enthält Ihre eigenen Zusatzfelder mit Bezeichnung und Auswahlwerten. Genau das braucht ein Sprachmodell, das selbst API-Aufrufe vorbereiten soll: Es sieht, welche Felder es gibt, welche Pflicht sind und welche Werte ein Auswahlfeld annimmt.

In der Praxis haben sich zwei Wege bewährt. Beim ersten lädt der Workflow die Spezifikation, schneidet die benötigten Teile heraus, etwa das Schema für ActionCreate und die Zusatzfelder am Kunden, und gibt sie dem Sprachmodell als Kontext mit. Das Modell liefert JSON, und n8n führt den Aufruf aus. Beim zweiten Weg bekommt ein KI-Agent-Knoten in n8n einzelne HTTP-Request-Werkzeuge, etwa „Kunde suchen" und „Aktivität anlegen", deren Beschreibung Sie aus der Spezifikation übernehmen. Die vollständige Spezifikation einem Modell auf einmal zu geben, ist meist zu viel; beschränken Sie sich auf die Endpunkte, die der Workflow tatsächlich nutzen soll. Mit ?neutral=1 erhalten Sie eine Fassung ohne Ihre Mandantenfelder.

Ein Prompt-Baustein für die Vorbereitung eines Aufrufs:

Rolle: Du bereitest Einträge für das CRM ameax vor. Du rufst selbst keine
Schnittstelle auf, sondern lieferst ausschließlich JSON.

Eingabe:
- Text: {{ Gesprächsnotiz oder E-Mail }}
- Kunde: {{ id, name aus GET /api/v2/customers }}
- Erlaubte Felder für eine Aktivität: {{ Auszug ActionCreate aus openapi.json }}
- Erlaubte Werte "Lead-Quelle": {{ Auswahlwerte des Zusatzfelds }}

Regeln:
- subject höchstens 250 Zeichen, sachlich, ohne Wertung.
- Nur Werte aus den erlaubten Listen verwenden, sonst null.
- Wenn der Kunde oder Ansprechpartner nicht eindeutig ist: "unsicher": true.

Ausgabe:
{
  "subject": "...",
  "notice": "...",
  "lead_source": "..." | null,
  "next_step": { "date": "JJJJ-MM-TT", "subject": "..." } | null,
  "unsicher": true | false,
  "begruendung": "..."
}

Der Workflow prüft die Ausgabe, bevor er schreibt: Ist unsicher gesetzt, legt er statt einer Änderung eine Wiedervorlage für einen Menschen an.

10. Den Webhook-Posteingang aus n8n beschicken

Nicht jeder Text muss in n8n zerlegt werden. Wenn ameax selbst Firma und Person erkennen und zuordnen soll, übergibt n8n den Rohtext an den Webhook-Posteingang. Die Quelle im Pfad ist eine Bezeichnung, an der Sie die Herkunft erkennen; inbox ist die ID des Posteingangs, format ist text, json oder csv.

curl -X POST "https://ihrefirma.ameax.de/p/webhook/n8n?inbox=3&format=text" \
  -H "Authorization: Bearer IHR_WEBHOOK_TOKEN" \
  -H "Content-Type: text/plain; charset=utf-8" \
  --data-binary @anfrage.txt

Im HTTP-Request-Knoten entspricht das einer POST-Anfrage mit dem Text als Body. Statt Authorization ist auch der Header X-Webhook-Token möglich. Ist das Token fest an einen Posteingang gebunden, entfällt die Wahl des Posteingangs. Die Antwort:

{
  "success": true,
  "received": true,
  "id": 42,
  "inbox": "Leads",
  "status": "processed",
  "url": "..."
}

Der Status zeigt, was passiert ist: processed heißt übernommen, suggested heißt, dass die Zuordnung nicht eindeutig war und ein Mensch sie in ameax prüft, failed heißt, dass die Verarbeitung gescheitert ist, der Text aber gespeichert bleibt. Automatisch übernommen wird nur, wenn es genau einen passenden Kunden mit ausreichend sicherer Zuordnung gibt, zum Beispiel über Domain oder Prüfsumme.

Was in ameax sichtbar wird

Eine gute Anbindung erkennt man daran, dass Ihr Team in ameax nichts suchen muss. Aktivitäten, die ein Workflow anlegt, stehen im Verlauf des Kunden, erkennbar an der eigenen Aktivitätsart und am Verfasser. Wiedervorlagen, die ein Workflow für einen Menschen anlegt, erscheinen in der Wiedervorlagenliste der zuständigen Person oder des Teams. Verkaufschancen mit geänderter Phase oder Wahrscheinlichkeit fließen in Forecast und Pipeline ein, Kampagnenstatus in die Kampagnenauswertung. Vorgänge und öffentliche Kommentare sehen Ihre Kunden im Kundenportal.

Nachrichten aus dem Webhook-Posteingang, die nicht eindeutig zugeordnet werden konnten, stehen mit Status „vorgeschlagen" zur Prüfung in ameax bereit. Und die Token-Verwaltung zeigt, welche Zugänge es gibt und für welchen Benutzer sie gelten. Damit lässt sich jederzeit beantworten, welcher Workflow mit welchen Rechten arbeitet.

Best Practices und Stolperstellen

Filter kennen keine Operatoren

Schreibweisen wie filter[amount][gte]=1000 oder filter[name][like]=… funktionieren nicht. Es gibt nur Gleichheit und den Stern als Platzhalter; bei Belegen zusätzlich den Datumsbereich filter[date]=2026-01-01..2026-03-31. Alles andere filtert der Workflow nach dem Abruf selbst. Ein unbekanntes Filterfeld liefert 400 mit der Liste der zulässigen Felder, was beim Bauen hilft.

Lesbare Felder nicht zurückschicken

Felder wie id, created_at, updated_at oder updated_by sind nur lesbar. Ein Workflow, der einen gelesenen Datensatz unverändert zurückschickt, bekommt 422 mit read_only. Ändern Sie mit PATCH und nur mit den Feldern, die sich ändern sollen.

Status von Verkaufschancen sind IDs

Der Status einer Verkaufschance ist eine interne ID, in der Standardeinrichtung 14 für aktiv, 15 für gewonnen, 16 für verloren, 17 für passiv, 18 für eingestellt und 19 für storniert. Phasen sind ebenfalls IDs. Setzen Sie salestatus beim Anlegen immer ausdrücklich, und hinterlegen Sie alle IDs in einem zentralen Konfigurationsknoten, statt sie in jedem Aufruf zu wiederholen.

Prozess-Button: success prüfen

Ein Prozess-Button antwortet mit 200, auch wenn er nicht ausgeführt wurde, zum Beispiel weil eine Vorbedingung nicht erfüllt ist. Wer nur den Statuscode prüft, hält einen Fehlschlag für einen Erfolg.

POST /customers prüft keine Dubletten

Die Anlage über die API prüft keine Dubletten und ordnet keinen Betreuer und kein Gebiet zu. Suchen Sie vor jedem Anlegen per filter[email], filter[external_id] oder Kundenkennung, und setzen Sie agent_id selbst, ermittelt aus den PLZ-Gebieten unter /api/v2/agent-territories. Wenn Sie die Prüfung von ameax nutzen wollen, ist der Webhook-Posteingang der bessere Weg für Neukunden.

Kampagnenstatus und Aktivität gehören zusammen

Ein Statuswechsel über PATCH /api/v2/customer-projects/{id} mit neuem type_id schreibt keine Aktivität und keine Statushistorie. Legen Sie die Aktivität im selben Workflow an. Eine doppelte Zuordnung eines Kunden zu derselben Kampagne beantwortet die API mit 422 already_exists; suchen Sie die bestehende Zuordnung vorher und ändern Sie sie.

E-Mails verschickt nicht die API

Die API v2 versendet keine E-Mails und legt keine Automailer-Einträge an. Mails verschickt entweder der Workflow selbst, oder er löst einen Prozess-Button aus, der einen E-Mail-Schritt enthält. Im zweiten Fall bleibt der Text in ameax und wird dort gepflegt.

Fazit

Die Anbindung von n8n an ameax braucht keinen eigenen Knoten, sondern ein sauber eingerichtetes Token, einen HTTP-Request-Knoten und die Kenntnis weniger Konventionen: JSON als Body, Gleichheitsfilter, Blättern mit page und per_page, zeitgesteuertes Abfragen über sort=-updated_at und ein gespeicherter Zeitstempel. Wer dazu Fehler auswertet, vor dem Anlegen sucht und success bei Prozess-Buttons prüft, hat eine Grundlage, auf der jedes Szenario aufsetzen kann.

Welche Abläufe sich damit umsetzen lassen, zeigt die Übersicht zur Automatisierung, etwa der Leadeingang oder die Gesprächsnachbereitung. Alle Endpunkte und Felder stehen in der API-Referenz.