28.09.2026

• Bugfixes:
  • Kundenfilter nach geburtsdatum (API & MCP): Seit dem 25.09.2026 lehnte der Filter ein Geburtsdatum mit Uhrzeit ab („Geburts- / Gründungsdatum entspricht nicht dem gültigen Format für Y-m-d."), auch den Wert, den die API selbst in Kunden-Antworten liefert (1995-01-06T00:00:00.000000Z). Integrationen, die diesen Wert unverändert zurückgeben (z.B. Make oder n8n), fanden dadurch keine Kunden mehr.
    • Ein Datum (1995-01-06) und ein Zeitpunkt nach ISO 8601 werden jetzt wieder angenommen. Ein Zeitpunkt trifft den Tag, auf den er in deutscher Zeit (Europe/Berlin) fällt.
    • Beispiel: 1995-01-06T00:00:00.000000Z und 1995-01-05T23:00:00.000Z (Mitternacht deutscher Zeit, in UTC angegeben) finden beide Kunden mit Geburtsdatum 06.01.1995.
    • Unvollständige Angaben (z.B. 1969 oder 1969-11) werden weiterhin mit einem Validierungsfehler (API: 422) abgelehnt.

25.09.2026

• Neue Funktionen:
  • Fester Datensatz für Zoho-Verknüpfungsfelder: Im Reiter "Felder" einer Pipeline kann einem Zoho-Feld vom Typ "Verknüpfung" (Lookup) jetzt ein fester Datensatz zugeordnet werden. Bisher blieb die Auswahl dafür leer.
    • Der Datensatz wird direkt in Zoho gesucht, ab 2 eingegebenen Zeichen. Neben jedem Treffer steht seine Zoho-ID, sodass sich gleichnamige Datensätze unterscheiden lassen.
    • Übertragen wird die Zoho-ID des gewählten Datensatzes. Der Name wird nur zur Anzeige gespeichert: Wird der Datensatz in Zoho umbenannt, zeigt der Reiter weiterhin den Namen, mit dem er ausgewählt wurde.
    • Ein fester Wert, der vor dieser Änderung gespeichert wurde, wird als „Zoho-ID …" angezeigt.
    • Schlägt die Suche fehl, steht der Grund unter dem Auswahlfeld; der gespeicherte Datensatz bleibt erhalten.
  • Hinweis auf feste Werte, die nicht übertragen werden: Ein fester Wert auf einem Verknüpfungs-, Besitzer-, Layout- oder Benutzerfeld, der keine gültige Zoho-ID ist (z.B. ein eingetippter Firmenname), wurde schon bisher nicht an Zoho übertragen, allerdings ohne Hinweis. Jetzt warnt das Speichern des Reiters "Felder" davor, und die Warnung erscheint auch im Reiter "Status". Gespeichert wird trotzdem. Am Feld selbst steht „keine gültige Zoho-ID – wird nicht übertragen".
• Anpassung Kundenfilter (API & MCP):
  • Zeitstempel-Filter: last_simplr_login_at und maklervollmacht_created_at werden jetzt in deutscher Zeit (Europe/Berlin) gelesen. Ein Jahr (2024), ein Monat (2024-05 oder 2024/05) oder ein Datum (2024-05-01 oder 2024/05/01) trifft das ganze Kalenderjahr, den ganzen Monat bzw. den ganzen Tag. Bisher traf ein Datum nur Mitternacht UTC und damit fast nie eine tatsächliche Anmeldung.
    • Beispiel: "last_simplr_login_at": "2024-05-01" findet alle Anmeldungen am 1. Mai von 00:00 bis 23:59:59 Uhr deutscher Zeit.
    • Ein Zeitpunkt nach ISO 8601 trifft sekundengenau: mit Z oder Offset (+02:00 oder +0200), auch ohne Sekunden oder mit Millisekunden. Ohne Offset gilt deutsche Zeit.
    • Ein Zeitstempel aus einer Kunden-Antwort der API kann unverändert als Filterwert verwendet werden.
    • Das gilt ebenso für die MCP-Werkzeuge zum Filtern, Auswerten und Exportieren von Kunden.
  • Werte, die kein gültiges Datum sind (z.B. 2024-13, 24 oder 01.05.2024), werden jetzt mit einem Validierungsfehler (API: 422) abgelehnt. Bisher führten unvollständige Angaben zu einem Fehler 500 (API) bzw. einer allgemeinen Fehlermeldung (MCP). Ein gültiger Wert vor 1970 oder nach 2038 findet keine Kunden, auch am Rand des Kalenders (z.B. 0000-01-01T00:00:00), wo bisher ebenfalls ein Fehler kam.
  • Ein unvollständiges geburtsdatum (z.B. 1969) wird jetzt ebenfalls mit einem Validierungsfehler (API: 422) abgelehnt. Erwartet wird ein Datum im Format JJJJ-MM-TT. Bisher führte es zu einem Fehler 500.
• Anpassung Kunden aktualisieren (API & MCP):
  • Einträge gezielt leeren mit _clear: Beim Aktualisieren (PUT kunde/{kunde}) und beim Upsert (PUT kunde/upsert) sowie mit den entsprechenden MCP-Werkzeugen lassen sich Kommunikationseinträge und Details jetzt ausdrücklich leeren. _clear ist eine Liste aus kommunikation.{art} oder details.{feld_id}.
    • Beispiel: "_clear": ["kommunikation.telefon"] löscht die Telefonnummer des Kunden in der Ameise.
    • Setzt derselbe Aufruf einen genannten Eintrag zugleich (auch in _default), wird er mit einem Validierungsfehler (API: 422) abgelehnt, ebenso ein unbekannter Eintrag.
    • Legt ein Upsert einen neuen Kunden an, wird _clear ignoriert.
  • Ein Wert null für einen Kommunikationseintrag oder ein Detail lässt den gespeicherten Eintrag jetzt auch über MCP unverändert. Bisher löschte das MCP-Werkzeug zum Aktualisieren von Kunden den Eintrag in der Ameise; die API hat null schon immer übergangen. (MCP)
• Anpassung Kunden anlegen und Upsert (API & MCP):
  • Pflichtangaben beim Upsert (MCP): Das MCP-Werkzeug zum Upsert verlangt jetzt wie die API bei jedem Aufruf Anrede, Vorname, Nachname und Land, bei einer juristischen Person auch rechtsform_id: direkt oder in _default, auch wenn die Suche einen Kunden findet. Ob sie einen findet, hängt von Daten ab, die sich ändern können; ein Aufruf ohne diese Angaben würde sonst nur so lange funktionieren, wie der Kunde gefunden wird. Bei einem Treffer bleiben die Werte aus _default ungenutzt. Bisher prüfte MCP diese Angaben nicht, und ein unvollständiger Kunde wurde erst von der Ameise abgelehnt.
  • Beim Aktualisieren eines Kunden wird rechtsform_id nicht mehr verlangt, auch bei einer juristischen Person. Sie wird nicht an die Ameise übertragen.
  • Upsert ohne Suchbedingung: Ergibt _search keine Suchbedingung, etwa weil der Wert eines Suchfelds nur in _default steht, wird der Upsert jetzt mit einem Validierungsfehler abgelehnt. Bisher traf eine leere Suche jeden Kunden im Zugriffsbereich, und ein einzelner Treffer wurde überschrieben. Über MCP werden die Suchfelder in _search jetzt wie bei der API geprüft; dort führte bisher schon ein Tippfehler im Suchfeld zu diesem Ergebnis.
  • Kommunikation und Details (MCP): Das MCP-Werkzeug zum Anlegen und das zum Upsert übernehmen Kommunikationseinträge und Details jetzt wie die API. Bisher führte jedes Detail zu einem Fehler, jeder Kommunikationseintrag wurde als privat angelegt, bei einem bestehenden Kunden kam ein zweiter Standard-Eintrag hinzu, und Kommunikationseinträge aus _default gingen verloren.
  • Kunden-Tags (MCP): Tags werden jetzt wie bei der API geprüft: erlaubt sind Buchstaben (mit Umlauten und ß), Ziffern, Leerzeichen und _ - : ( ) / ?, höchstens 255 Zeichen, ohne doppelte Tags. Bisher nahm MCP beliebige Tags an.
• Anpassung Archiv-Einträge anlegen (API & MCP):
  • Bei Dokumenten (typ dokument) ist betreff jetzt optional. Fehlt er, wird der Dateiname verwendet (auf 100 Zeichen gekürzt). Über MCP wird ein angegebener Betreff jetzt übernommen; bisher wurde er bei Dokumenten durch den Dateinamen ersetzt.
  • Ein zugeordneter Vertrag muss jetzt zu diesem Kunden gehören und für das Token zugänglich sein (Vermittler-Einschränkung). Andernfalls wird der Eintrag mit einem Validierungsfehler abgelehnt. Bisher ließ sich ein Eintrag jedem Vertrag des Mandanten zuordnen, über MCP sogar einer nicht vorhandenen Vertrags-ID. Eine zugeordnete Sparte muss jetzt auch über MCP im Mandanten vorhanden sein.
  • Über MCP werden jetzt Dokumente bis 10 MB angenommen (bisher 5 MB), wie bei der API. Dateinamen mit der Endung .jpeg oder mit einer Endung in Großbuchstaben werden akzeptiert. Der MIME-Typ image/jpg entfällt; JPEG-Bilder werden als image/jpeg übergeben. (MCP)
• Bugfixes:
  • Länderkennung bei Bankverbindungen und zusätzlichen Adressen (API & MCP): Die Länderkennung nation wird beim Ändern der Bankverbindung eines Vertrags und beim Anlegen oder Ändern einer zusätzlichen Adresse eines Kunden jetzt in Kleinbuchstaben an die Ameise übertragen, die nur diese Schreibweise kennt. DE und de werden gleich behandelt. Bei zusätzlichen Adressen lehnte die Ameise DE über die API bisher ab.
  • Geburtsdatum in der Antwort (API & MCP): Beim Anlegen und Aktualisieren eines Kunden enthielt das zurückgegebene geburtsdatum bisher die Uhrzeit der Anfrage (z.B. 1990-05-15T14:28:58.000000Z). Es lautet jetzt auf Mitternacht (1990-05-15T00:00:00.000000Z). Gespeichert und an die Ameise übertragen wurde schon bisher nur das Datum.
  • Vertrags-Export (MCP): Die Standardspalten kunde_nachname, sparte_name und gesellschaft_name waren in jedem Vertrags-Export leer und konnten nicht ausdrücklich angefordert werden. Sie werden jetzt befüllt. Listenwerte mit ungültigen Zeichen erscheinen in Exporten nicht mehr als FALSE (Excel) bzw. leer (CSV, PDF).
  • Zoho-Verknüpfungsfelder: Eine Zahl, die zu groß für eine Zoho-ID ist, wird jetzt wie jeder andere ungültige Wert nicht übertragen. Bisher wurde sie verfälscht übertragen, und Zoho lehnte den ganzen Datensatz ab. Ein fester Layout-Wert, der keine Layout-ID ist, wird jetzt auch bei Massenübertragungen weggelassen, wie schon bei einzelnen Übertragungen.
  • Pipeline-Vorschau: Fehlen einer Pipeline das CRM-Modul oder das Identifikationsfeld, zeigt die Vorschau jetzt den Hinweis, zuerst ein Modul zu wählen. Bisher kam ein Serverfehler.
  • Aktivitätsprotokoll: Der Zeitraum-Filter wird jetzt in der Zeitzone des Benutzers gelesen, in der Liste ebenso wie im CSV-Export. Bisher wurde er als UTC gelesen, sodass sich der Zeitraum um ein bis zwei Stunden verschob.
  • API-Tokens: Im Formular zum Anlegen und Bearbeiten eines Tokens trat ein JavaScript-Fehler auf, durch den die Optionen, die von den gewählten Berechtigungen abhängen, nicht passend ein- und ausgeblendet wurden.
  • Ablaufdatum von API-Zugängen: Ein eigenes Ablaufdatum für API-Tokens und OAuth-Verbindungen wird beim Erstellen, Bearbeiten und auf der Freigabeseite jetzt in der Zeitzone des Benutzers gelesen und angezeigt. Bisher wurde es als UTC gelesen: Ein Zugang mit Ablauf um Mitternacht deutscher Zeit lief so ein bis zwei Stunden zu spät ab. Wird das Formular unverändert gespeichert, bleibt das Ablaufdatum sekundengenau erhalten.
    • Ein Ablaufdatum ab dem 19.01.2038, 04:14:07 Uhr deutscher Zeit, kann technisch nicht gespeichert werden. Es wird jetzt mit einer Fehlermeldung abgelehnt; bisher führte es zu einem Serverfehler.
  • Analyse-Werkzeuge (MCP): Ungültige Argumente, etwa eine unbekannte Operation oder ein unbekanntes Feld, werden jetzt mit der zugehörigen Fehlermeldung beantwortet. Bisher kam nur „Failed to execute analytics operation", ohne Hinweis darauf, welches Argument zu korrigieren ist.
• Sonstige Änderungen:
  • Die API-Dokumentation beschreibt jetzt den Request-Body jedes schreibenden Endpunkts, einschließlich _clear und _search.
  • Fehlermeldungen zu Tags und zu _search nennen das Feld jetzt verständlich („Tag", „Suchfeld") statt eines internen Schlüssels wie tags.0.

MCP-Clients, die Kommunikationseinträge oder Details bisher mit null gelöscht haben, müssen dafür jetzt _clear verwenden.

MCP-Clients, die den Upsert ohne Anrede, Vorname, Nachname oder Land aufrufen, erhalten jetzt einen Validierungsfehler. Die Angaben können in _default übergeben werden.

MCP-Clients, die Kunden-Tags mit Zeichen wie . oder & setzen, erhalten dafür jetzt einen Validierungsfehler. Solche Tags lehnte die API schon bisher ab.

Integrationen, die kunde/filter mit last_simplr_login_at oder maklervollmacht_created_at nutzen, sollten prüfen, ob sie ein Datum oder einen Zeitpunkt ohne Offset senden: Beide werden jetzt in deutscher Zeit gelesen.

23.09.2026

• Neue Funktionen:
  • Verbinden per OAuth (API & MCP): Integrationen und MCP-Clients, die OAuth unterstützen, können sich jetzt direkt mit einem Mandanten verbinden. Ein API-Token muss dafür nicht mehr von Hand erstellt und eingefügt werden — ein angemeldeter Benutzer bestätigt die Verbindung auf einer Freigabeseite.
    • Auf der Freigabeseite werden wie bei einem API-Token Name, Berechtigungen, Ablaufdatum, Vermittler-Nummern, Regionen und erlaubte IP-Adressen festgelegt.
    • Eine Verbindung gilt entweder für die API oder für MCP. Wer beides nutzt, verbindet den Client zweimal.
    • Ist der Client bereits verbunden, kann die bestehende Verbindung beim erneuten Verbinden ersetzt werden. Statistiken und Verlauf bleiben dabei erhalten.
    • Ein Client, der sich zum ersten Mal verbindet, muss einmalig vom Support freigegeben werden. Der Support wird darüber automatisch informiert; bis zur Freigabe sieht der Benutzer einen Hinweis.
    • Für Entwickler: Authorization Code mit PKCE (S256), Discovery nach RFC 8414 und RFC 9728, Clients per Client-ID-Metadata-Dokument oder dynamischer Registrierung (RFC 7591). Access-Tokens gelten eine Stunde, Refresh-Tokens 30 Tage und verlängern sich bei jeder Nutzung.
  • API-Zugänge: Die Seite „API Tokens" heißt jetzt „API-Zugänge" und zeigt neben den API-Tokens auch alle OAuth-Verbindungen, jeweils mit Client und dem Benutzer, der sie hergestellt hat.
    • Administratoren können OAuth-Verbindungen dort bearbeiten (Name, Berechtigungen, Ablaufdatum, Einschränkungen) oder entfernen. Eine Änderung gilt ab der nächsten Anfrage, das Entfernen sperrt den Zugang sofort.
    • Bei neu erstellten API-Tokens wird ebenfalls angezeigt, wer sie erstellt hat.
  • whoami (API): Die Antwort enthält zusätzlich type (manual oder oauth), abilities, client und access_token_expires_at (Ablauf des verwendeten stündlichen Access-Tokens einer OAuth-Verbindung).
• Anpassung Authentifizierung (API & MCP):
  • Das Token wird ab jetzt nur noch für bestehende API-Tokens auch als Query-Parameter ?_token= akzeptiert. Neu erstellte API-Tokens und OAuth-Verbindungen müssen das Token im Authorization-Header übergeben; eine Übergabe per ?_token= wird mit 401 und dem Code QUERY_TOKEN_NOT_ALLOWED abgelehnt.
  • Im Aktivitätsprotokoll werden Änderungen über API und MCP jetzt dem jeweiligen API-Zugang zugeordnet. Einträge vor dem 23.09.2026 erscheinen weiterhin unter dem bisherigen Token.
• Sonstige Änderungen:
  • Der MCP-Server unterstützt zusätzlich die MCP-Protokollversion 2026-07-28. Bestehende MCP-Clients funktionieren unverändert. (MCP)

In der whoami-Antwort wird expires_at jetzt im selben Format wie created_at ausgegeben (z.B. 2026-09-23T12:00:00+00:00 statt 2026-09-23T12:00:00.000000Z). Integrationen, die dieses Feld auswerten, sollten das Format prüfen.

Wir empfehlen, auch bestehende Integrationen, die das Token per ?_token= übergeben, auf den Authorization-Header umzustellen.

11.09.2026

• Bugfixes:
  • Ameise-Verbindung: Die Verbindung zu Ameise wurde bei einigen Mandanten wiederholt getrennt und musste von Hand neu hergestellt werden. Ursache war eine doppelte Erneuerung des Zugriffs, die Ameise als Missbrauch wertet und mit der Sperrung der Verbindung beantwortet. Das ist behoben.
  • Zoho-Verbindung: Wenn Zoho Anfragen vorübergehend drosselte, wurde die Verbindung getrennt und musste neu hergestellt werden. Eine Drosselung führt jetzt nicht mehr zur Trennung; unnötige Erneuerungen des Zugriffs, die zur Drosselung beigetragen haben, finden nicht mehr statt.

10.09.2026

• Neue Funktionen:
  • Wöchentliche Meldung „Fehlerhafte Feld-Zuordnungen": Eine neue Benachrichtigung meldet jeden Montag um 09:00 Uhr, in welchen aktiven Pipelines Werte nicht übertragen werden, weil die Feld-Zuordnung sie nicht abdeckt. Bisher fiel das nur auf, wenn jemand die Pipeline gezielt geprüft hat — übertragen wurde trotzdem, nur eben ohne die betroffenen Angaben.
    • Gemeldet werden: Ameise-Pflichtfelder, die kein Mapping befüllt; CRM-Auswahlwerte ohne passende Option in der Wertzuordnung (sie werden bei jedem Import geleert); Verknüpfungen, die ins Leere zeigen (verknüpfte Pipeline gelöscht, archiviert, ohne Identifikationsfeld oder zirkulär); Zuordnungen, deren Wert als Datensatz-ID an das CRM gehen soll, obwohl die Ameise-Seite keine liefern kann; sowie Pipelines, bei denen Modul oder Identifikationsfeld noch fehlen.
    • Zu jedem Punkt steht der konkrete nächste Schritt, und jede betroffene Pipeline ist direkt mit ihrem Reiter „Felder" verlinkt.
    • Die Mail kommt nur, wenn es tatsächlich etwas zu melden gibt, und wiederholt sich wöchentlich, solange die Zuordnung unverändert bleibt.
    • Aufgeführt werden höchstens 10 Pipelines mit je höchstens 10 Punkten. Alles Weitere wird gezählt und benannt; vollständig sichtbar ist es im Reiter „Felder".
    • Pipelines, deren CRM zum Zeitpunkt der Prüfung nicht erreichbar war, werden nicht als fehlerhaft gemeldet, sondern nur gezählt — eine Störung ist keine Fehlkonfiguration.
    • Geprüft werden ausschließlich aktive, nicht archivierte Pipelines. Für deaktivierte Pipelines greift weiterhin die Prüfung beim Aktivieren.

Die neue Benachrichtigungsart „Fehlerhafte Feld-Zuordnungen" steht unter „Fehler-Benachrichtigungen" zur Auswahl. Bestehende Empfänger, die CRM-Push-Fehler abonniert haben, wurden dafür eingetragen; bei ihnen kommt die Meldung ohne weiteres Zutun an. Alle übrigen Empfänger müssen die Art einmalig selbst auswählen — ohne bestätigten Empfänger wird ein Mandant weder geprüft noch benachrichtigt.

• Anpassung Benachrichtigungen:
  • „Pipeline deaktiviert" und „Webhook deaktiviert" sind jetzt abonnierbar: Beide Meldungen gingen bisher immer an alle Administratoren des Mandanten und ließen sich weder umleiten noch abbestellen. Sie stehen jetzt wie alle übrigen Meldungen als eigene Benachrichtigungsart unter „Fehler-Benachrichtigungen" zur Auswahl — getrennt voneinander, weil den Webhook-Empfänger und die Pipelines selten dieselbe Person betreut.
    • Bestehende Empfänger, die CRM-Verbindung getrennt abonniert haben, wurden für beide neuen Arten eingetragen; bei ihnen kommen die Meldungen unverändert an. Neu angelegte Administratoren-Empfänger sind von Anfang an eingetragen.
    • Zu beachten: Die Meldungen folgen jetzt der Empfängerliste. Ein Administrator, der dort nicht als bestätigter Empfänger steht, erhält sie nicht mehr automatisch.
  • Verständlichere Meldungen bei Deaktivierung: Die drei Mails „CRM-Verbindung deaktiviert", „Pipeline deaktiviert" und „Webhook deaktiviert" waren bisher wortgleich und nannten weder das betroffene Objekt noch den nächsten Schritt.
    • Betreff und Text nennen jetzt die betroffene Verbindung, Pipeline bzw. das Abonnement, und was dadurch stillsteht.
    • Jede Mail sagt, was konkret zu tun ist — und das unterscheidet sich: eine Verbindung braucht meist eine neue Anmeldung, eine Pipeline eine korrigierte Feld-Zuordnung, ein Webhook einen erreichbaren Empfänger.
    • Bei der CRM-Verbindung richtet sich der Hinweis nach der tatsächlichen Ursache. Eine abgelaufene Lizenz, ein deaktivierter CRM-Benutzer oder eine zeitweise Drosselung durch das CRM führen nicht mehr zur pauschalen Aufforderung, sich neu anzumelden — bei einer Drosselung genügt es, die Verbindung später wieder zu aktivieren.
    • Werden zwei verschiedene Pipelines kurz nacheinander deaktiviert, erhalten Sie jetzt zu beiden eine Meldung. Bisher wurde die zweite innerhalb der Ruhephase unterdrückt.
• Anpassung Pipelines:
  • Die Aktivierung blockiert nicht mehr an Feldern, die das System selbst füllt: Bei Vertrags-Pipelines meldete die Prüfung beim Aktivieren bisher fünf Ameise-Pflichtfelder als „wird nicht befüllt", obwohl Qonekto sie bei jeder Übertragung automatisch setzt: Vermittler, Status, Gesellschaft, Sparte und Zahlweise. Diese Felder verhindern die Aktivierung nicht mehr.
    • Verschwiegen werden sie deshalb nicht: Der Reiter „Status" führt sie jetzt unter „Hinweise" auf, mit dem Zusatz, dass sie automatisch mit einem Standardwert gesendet werden. Bei Gesellschaft und Sparte sind das Platzhalter („00000" bzw. „999") — wer dort echte Werte erwartet, muss die Felder weiterhin zuordnen.
    • Die Versicherungsscheinnummer hat keinen Standardwert und blockiert die Aktivierung weiterhin, solange sie von keinem Mapping befüllt wird.
    • Ist beim Mandanten keine Ameise-Vermittlernummer hinterlegt, gilt der Vermittler nicht mehr als automatisch gefüllt: Die Aktivierung wird dann verlangen, dass er zugeordnet wird. Bisher wurden solche Verträge mit leerem Vermittler übertragen, ohne dass darauf hingewiesen wurde.

07.09.2026

• Neue Funktionen:
  • Kundenarchiv und Vertragsdokumente auslesen (API & MCP): Das Archiv eines Kunden und die Dokumente eines Vertrags lassen sich jetzt auslesen — bisher konnten Archiveinträge nur angelegt werden.
    • Neue Endpunkte GET kunde/{kunde}/archiveintrag und GET vertrag/{vertrag}/dokument, dazu die neuen MCP-Werkzeuge "Kundenarchiv auflisten" und "Vertragsdokumente auflisten".
    • Jeder Eintrag und jeder Anhang enthält eine signierte Download-Adresse (download_url), über die die Datei ohne weitere Anmeldung geladen wird. Die Adresse ist 15 Minuten gültig.
    • Vertragsdokumente führen keinen Typ und keine Anhänge — die Ameise liefert diese Angaben dort nicht.
    • Eine Download-Adresse kann bis zu 20-mal pro Minute abgerufen werden, danach antwortet die Schnittstelle mit 429. Die Grenze gilt je Adresse, nicht je Mandant.
    • Schlägt ein Download fehl, nennt die Antwort den Grund: Eintrag nicht gefunden (ARCHIVE_ENTRY_NOT_FOUND), Eintrag gehört nicht zum angegebenen Kunden (ARCHIVE_ENTRY_NOT_LINKED) oder Eintrag enthält keine Datei (ARCHIVE_ENTRY_NO_CONTENT).
  • Schutz vor doppelten Schreibvorgängen (API): Alle schreibenden Endpunkte akzeptieren jetzt den Header Idempotency-Key. Wird derselbe Schlüssel innerhalb von 24 Stunden erneut mit identischem Inhalt gesendet, antwortet die Schnittstelle mit der gespeicherten Antwort des ersten Aufrufs — gekennzeichnet durch den Antwort-Header Idempotency-Replayed: true — statt einen zweiten Datensatz anzulegen.
    • Derselbe Schlüssel mit abweichendem Inhalt wird mit 422 (IDEMPOTENCY_KEY_REUSED) abgelehnt.
    • Läuft der erste Aufruf noch, wartet der zweite bis zu 30 Sekunden und erhält dann 409 (IDEMPOTENT_REQUEST_IN_PROGRESS) mit Retry-After.
    • Zwei gleichzeitige Kunden-Upserts mit denselben Suchkriterien werden nacheinander ausgeführt; der zweite erhält gegebenenfalls 409 (CONCURRENT_CUSTOMER_WRITE) und sollte wiederholt und nicht als Neuanlage gesendet werden. Das gilt auch für das MCP-Werkzeug "Kunde anlegen oder aktualisieren".
    • Scheitert ein Aufruf erst, nachdem der Datensatz in der Ameise bereits angelegt wurde, wird dieser Datensatz bei der Wiederholung vervollständigt, statt ein zweites Mal angelegt zu werden.
    • Nur erfolgreiche Antworten werden wiederholt. Nach einem Fehler läuft ein korrigierter Aufruf normal.
  • Webhooks für gelöschte Datensätze: Für Kunde, Vertrag, Kunden-Detail und Kunden-Kommunikation kann jetzt auch auf "Entfernt" reagiert werden. Bisher war diese Kombination zwar auswählbar, ausgelöst wurde sie nie. Die Meldung enthält den entfernten Datensatz vollständig.
  • Webhook bei Archiv-Upload: Die neue Aktion "Archiveintrag erstellt" am Objekt Kunde meldet Archiveinträge, die über API oder MCP hochgeladen wurden. Direkt in der Ameise hinterlegte Einträge sind nicht enthalten, da sie dem System nicht bekannt werden.

Wichtig für API- und MCP-Nutzer: In Archiveinträgen und deren Anhängen entfallen die Felder datei, text und uri. Sie enthielten interne Ameise-Adressen, die nicht mehr nach außen gegeben werden — geladen wird ausschließlich über download_url. Zu beachten: Bei Notizen stand der Notiztext bisher im Feld text; er wird jetzt ebenfalls über download_url abgerufen. Der Dateiname bleibt als name erhalten. Außerdem wird download_url jetzt an jedem Eintrag ausgegeben, auch wenn dahinter keine Datei liegt — ob Inhalt vorhanden ist, zeigt erst der Download (404 ARCHIVE_ENTRY_NO_CONTENT). Die Gültigkeit sinkt von 60 auf 15 Minuten, und der Aufbau der Adresse hat sich geändert: früher gespeicherte Adressen funktionieren nicht mehr.

Wichtig für API-Nutzer: Der Schutz vor doppelten Schreibvorgängen greift auch ohne Header. Wird ein inhaltlich identischer Schreibaufruf innerhalb von 60 Sekunden mit demselben Token wiederholt, gilt er als Wiederholung und wird nicht erneut ausgeführt — zurückgegeben wird die Antwort des ersten Aufrufs. Wer bewusst zwei gleiche Datensätze kurz hintereinander anlegen möchte, muss dafür je einen eigenen Idempotency-Key senden. Wiederholte Aufrufe zählen weiterhin als Zugriff in der Abrechnung.

• Anpassung Webhooks:
  • Objekt und Aktion werden jetzt gemeinsam ausgewählt: Nach Auswahl des Objekts stehen nur noch die Aktionen zur Verfügung, die für dieses Objekt tatsächlich ausgelöst werden. Bisher waren 26 Kombinationen wählbar, von denen ein Teil nie eine Meldung erzeugt hat — die Ursache mehrerer Anfragen zu "Webhook löst nicht aus".
    • Bestehende Webhooks mit einer nicht mehr wählbaren Kombination bleiben erhalten, bearbeitbar und aktiv.
  • Der Webhook-Test sendet jetzt standardmäßig einen deutlich gekennzeichneten Beispiel-Payload (test: true, Platzhalterwerte) an die hinterlegte URL, statt die letzte echte Aktivität zu wiederholen. Der Test funktioniert damit auch bei einem gerade angelegten Webhook, überträgt in dieser Form keine Kundendaten und kann den Webhook nicht mehr deaktivieren oder eine Störungsmeldung auslösen.
  • Neu: Wer prüfen möchte, ob der eigene Empfänger (z.B. ein n8n- oder Make-Ablauf) einen echten Datensatz auch tatsächlich auflöst, kann beim Test die Option "Letzte echte Aktivität senden (statt Beispiel-Payload) — enthält echte Kundendaten" ankreuzen. Gesendet wird dann eine echte Aktivität des eigenen Mandanten, mit echten Kundendaten und in genau dem Aufbau, den auch eine reguläre Auslieferung hat.
    • Die Option gilt nur für den einen Test und ist beim nächsten Aufruf wieder leer.
    • Gesendet wird die jüngste passende Aktivität der letzten 90 Tage zu dem am Webhook eingestellten Objekt und der eingestellten Aktion. Gibt es keine, wird nichts gesendet und der Test weist darauf hin — es wird nicht ersatzweise der Beispiel-Payload verschickt.
    • Die Erfolgsmeldung nennt die gesendete Aktivität mit Zeitpunkt, Objekt und — soweit bekannt — Auslöser, sodass nachvollziehbar ist, was der Empfänger erhalten hat.
    • Auch diese Testart lässt den Webhook unverändert: Sie kann ihn nicht deaktivieren und löst keine Störungsmeldung aus.
    • Jeder Versand einer echten Aktivität wird im Aktivitätsprotokoll als "Webhook-Test mit echter Aktivität" festgehalten. Der Beispiel-Payload wird weiterhin nicht protokolliert.
    • Wie bisher ist der Webhook-Test Administratoren vorbehalten.
  • Die Webhook-Seite zeigt jetzt "Zuletzt ausgelöst" und "Zuletzt getestet". Ein Test verändert "Zuletzt ausgelöst" nicht mehr.
  • Der Schalter im Formular für einen neuen Webhook heißt jetzt "Erstellen" statt "Speichern".

Wichtig: Bestehende Webhooks auf die Aktion "Entfernt" haben bisher nie ausgelöst und werden mit dieser Version aktiv. Empfänger solcher Webhooks sollten vor der Freischaltung prüfen, ob sie den zusätzlichen Verkehr erwarten und verarbeiten können.

Wichtig für Webhook-Empfänger: Beide Testarten senden jetzt zusätzlich die Kopfzeile X-Webhook-Test — mit dem Wert sample für den Beispiel-Payload und replay für eine echte Aktivität. Der Beispiel-Payload behält daneben sein test: true im Inhalt; die echte Aktivität enthält bewusst keine solche Markierung, damit sie exakt einer regulären Auslieferung entspricht. Empfänger, die einen Test nicht ein zweites Mal verarbeiten dürfen, sollten daher auf diese Kopfzeile prüfen.

• Anpassung Daily-UP-Import:
  • Eine leere Pflichtdatei löscht keine Daten mehr: Kommt eine benötigte Exportdatei ohne Inhalt an, während im System noch Datensätze dieses Typs vorhanden sind, wird der Löschschritt für diesen Typ übersprungen und protokolliert. Bisher wurden dabei alle Datensätze dieses Typs entfernt — lokal und in den angebundenen CRMs.
  • Scheitert ein nächtlicher Import und wird er von der folgenden Nacht überholt, werden die bereits ermittelten Löschungen jetzt trotzdem an die CRMs und an die Webhook-Empfänger ausgeliefert. Bisher gingen sie verloren.
    • Ein stündlicher Prozess sucht zwischen 02:00 und 19:00 nach solchen liegen gebliebenen Schritten. Ausgeliefert wird erst, nachdem der überholende Import seine eigenen Daten erfolgreich übertragen hat — bis dahin wird gewartet. Bleibt diese Übertragung Nacht für Nacht aus, verzögert sich auch die Nachlieferung entsprechend.
    • Jeder liegen gebliebene Schritt erhält genau einen Versuch. Schlägt dieser fehl, wird der Schritt als "Fehler" ausgewiesen und nicht automatisch erneut versucht — so kann keine Löschung doppelt bei den Empfängern ankommen.
    • Nachgeliefert wird je Mandant nur der zuletzt überholte Import. Nach mehreren Fehlernächten hintereinander bleiben die älteren davon also liegen.
    • Datensätze, die der neuere Import wieder aufgenommen hat, werden dabei nicht gelöscht.
    • Die Importübersicht weist den abgebrochenen Schritt mit dem neuen Status "Übersprungen" aus. Der Import bleibt insgesamt als "Fehler" gekennzeichnet.
  • Die Fehlermeldung eines Imports nennt jetzt die Schritte, die durch den Abbruch liegen geblieben sind.
• Anpassung CRM-Synchronisierung:
  • Änderungen an einem bereits verknüpften Vertrag, die aus dem CRM eingehen, werden jetzt in die Ameise übertragen. Bisher war das dort technisch nicht möglich: Die Aktualisierung wurde zweimal wiederholt und ging dann verloren. Auch ein Vermittlerwechsel am Vertrag wird übertragen.
    • Einzelne Änderungen werden mit einer verständlichen Begründung abgelehnt, statt wiederholt zu werden — etwa ein Vertrag, der einem anderen Kunden zugeordnet werden soll, ein nicht unterstützter Status oder eine nicht unterstützte Zahlweise, sowie ein stornierter Vertrag ohne Stornogrund und Stornodatum.
• Bugfixes:
  • Archiv-Upload (API): Lehnt die Ameise einen Upload ab, wird jetzt deren eigene Fehlermeldung mit dem passenden Statuscode durchgereicht. Bisher kam ein allgemeiner Fehler 500, dessen Meldung interne Angaben zur ausgehenden Anfrage enthielt.
  • Aktivitätsprotokoll: Wird eine Telefonnummer oder E-Mail-Adresse über API, MCP oder das CRM geleert, steht im Protokoll jetzt der entfernte Wert statt eines leeren Feldes. Löschungen werden im Detail außerdem als Gegenüberstellung ("Entfernt") dargestellt.
  • Vermittler bei Vertragsanlage (API & MCP): Wird beim Anlegen eines Vertrags eine vermittler_id übergeben, die die Ameise für den verwendeten Zugang nicht kennt, antwortet die Schnittstelle jetzt mit 422 und nennt das Feld. Bisher wurde der Aufruf an die Ameise geschickt und kam von dort als allgemeiner Fehler 400 ohne Angabe des Feldes zurück.
    • Die Prüfung kommt zur bisherigen Prüfung hinzu. Ist die Vermittler-Liste gerade nicht abrufbar, wird der Aufruf wie bisher durchgelassen und die Ameise entscheidet — die Vertragsanlage kann dadurch nicht blockiert werden.
  • Kunden-Verknüpfungen blättern (API & MCP): GET kunde/{kunde}/relations und das MCP-Werkzeug "Kunden-Verknüpfungen auflisten" nehmen jetzt page und pageSize (im MCP: page und per_page) entgegen. Bisher wurden currentPage und numberOfPages zwar ausgegeben, es gab aber keine Möglichkeit, die zweite Seite anzufordern — alles jenseits der ersten Seite war nicht erreichbar.
    • Jeder Eintrag enthält jetzt zusätzlich brokerId und status. Die bisherigen Felder bleiben unverändert. Anlegen und Löschen einer Verknüpfung sind nicht betroffen.
  • Schadensfälle ohne Einträge (API & MCP): Die Schadensfall-Listen zu Vertrag und Kunde antworten jetzt mit einer leeren Liste, wenn keine Schadensfälle vorliegen. Bisher kam in diesem Fall ein Fehler 400, der nicht von einer Störung zu unterscheiden war.
    • Der Zugriff auf einen Vertrag außerhalb des eigenen Bestands bleibt ein Fehler. Der Abruf eines einzelnen unbekannten Schadensfalls antwortet jetzt 404 (CLAIM_NOT_FOUND) statt 400.
  • Unbekannte Kunden- und Vertrags-IDs im Archiv (API & MCP): Kennt die Ameise die angefragte Kunden- oder Vertrags-ID nicht, antworten Kundenarchiv und Vertragsdokumente jetzt mit 404 (ARCHIVE_CUSTOMER_NOT_FOUND bzw. ARCHIVE_CONTRACT_NOT_FOUND); die MCP-Werkzeuge weisen ausdrücklich darauf hin, dass die ID der Ameise unbekannt ist. Bisher kam ein allgemeiner Fehler 500. Andere Störungen werden weiterhin als 500 gemeldet.
  • Datumsangaben an die Ameise (API & MCP): Datumswerte für Aufgaben (dueDate, dueDateFrom, dueDateTo), Schadensfälle (claimDate, notificationDate) sowie das Geburtsdatum bei der Vertrags-Bankverbindung werden jetzt vor der Weitergabe in das von der Ameise erwartete Format (ISO 8601 mit Zeitzonen-Angabe) gebracht. Bisher wurde etwa 2026-03-05 von uns angenommen und anschließend von der Ameise abgelehnt. Wer bereits das dokumentierte Format sendet, merkt keinen Unterschied.
• Sonstige Änderungen:
  • Die API-Dokumentation ist auf dem aktuellen Stand: Der Header Idempotency-Key ist jetzt an allen schreibenden Endpunkten ausgewiesen, ebenso die neuen Fehlercodes und der Parameter pageSize.

04.09.2026

• Neue Funktionen:
  • Verknüpfungsfelder für Zoho-Pipelines: Zoho-Felder vom Typ "Verknüpfung" (Lookup) können jetzt mit einem Verknüpfungsfeld der Ameise befüllt werden. Ein als Abschluss übertragener Vertrag verweist in Zoho damit auf den Kontakt, als der sein Kunde übertragen wurde — bisher blieb diese Verbindung in Zoho leer.
    • Die Zuordnung erfolgt wie jede andere im Reiter "Felder" der Pipeline. Unterstützt werden die Verknüpfungen des Kunden (Vermittler, Anrede, Land, Rechtsform) und des Vertrags (Vermittler, Kunde, Sparte, Gesellschaft, Status, Zahlweise).
    • Zu jeder Verknüpfung wird die verknüpfte Pipeline angegeben — also die Pipeline, welche die verknüpften Datensätze nach Zoho überträgt. Kommt nur eine Pipeline in Frage, wird sie automatisch erkannt; kommen mehrere in Frage, wird sie beim Speichern abgefragt.
    • Aufgelöst wird die Verknüpfung von Zoho selbst, anhand des Identifikationsfeldes der verknüpften Pipeline. Übertragen wird also der Wert dieses Feldes und nicht die Zoho-ID des verknüpften Datensatzes.
    • Auch der umgekehrte Weg wird unterstützt: Eine aus Zoho eingehende Verknüpfung wird dem passenden lokalen Datensatz zugeordnet.
    • Beim Aktivieren wird geprüft, ob die Verknüpfung überhaupt funktionieren kann. Fehlt die verknüpfte Pipeline, ihr Identifikationsfeld oder die nötige Einstellung in Zoho, wird die Aktivierung mit einer konkreten Handlungsanweisung abgelehnt, statt später unbemerkt fehlzuschlagen. Auch zirkuläre Verknüpfungen werden erkannt und abgelehnt.
  • Panda-Ausschreibungen (API): Eine einzelne Ausschreibung kann jetzt gezielt abgerufen und eine Ausschreibung archiviert werden. Bisher ließen sich Ausschreibungen nur auflisten und anlegen.
    • Abruf einer Ausschreibung mit allen Details: Kunde, Branchen, Versicherungssparte, Backoffice sowie die Anfragen an die einzelnen Versicherer samt Status und ungelesenen Nachrichten. Mitgeliefert werden außerdem die Antworten aus dem Fragenkatalog — benötigt Lese-Berechtigung.
    • Archivieren einer Ausschreibung, optional mit Angabe einer Begründung — benötigt Schreib-Berechtigung. Das Archivieren kann über die Schnittstelle nicht rückgängig gemacht werden.

Voraussetzung für Verknüpfungsfelder: Das Identifikationsfeld der verknüpften Pipeline muss in Zoho ein externes Textfeld auf Organisationsebene sein. Diese Einstellung kann nur in Zoho selbst vorgenommen werden (Setup → Anpassung → Module und Felder → Modul → Feld → "Als externes Feld festlegen"), nicht über Qonekto.

Ist einem Zoho-Verknüpfungsfeld bisher ein Ameise-Feld zugeordnet, ändert sich das beim nächsten Speichern des Reiters "Felder":

• Ist auf Ameise-Seite ein Verknüpfungsfeld zugeordnet (z.B. Kunde oder Vermittler) und überträgt genau eine Pipeline die verknüpften Datensätze, übernimmt die neue Verknüpfung die Auflösung. Eine bisher gepflegte Werte-Zuordnung wird ab dann nicht mehr angewendet.
• Ist auf Ameise-Seite dagegen ein einfaches Feld zugeordnet (z.B. ein Namens- oder Textfeld), lässt sich der Reiter weiterhin speichern. Aus einem solchen Feld lässt sich jedoch kein Zoho-Datensatz ermitteln, daher wird es nicht mehr nach Zoho übertragen. Ein Hinweis dazu erscheint beim Speichern, im Reiter "Status" und in der Vorschau.
• Überträgt keine oder mehr als eine Pipeline die verknüpften Datensätze, lässt sich der Reiter ebenfalls erst speichern, nachdem die verknüpfte Pipeline ausgewählt bzw. angelegt wurde.

Betroffen sind ausschließlich Zoho-Felder vom Typ "Verknüpfung". Wird eine Ameise-Kennung wie bisher in ein normales Text- oder Zahlenfeld in Zoho geschrieben — etwa um sie dort über eine eigene Zoho-Automatisierung weiterzuverarbeiten — ändert sich daran nichts.
Bestehende Pipelines übertragen unverändert weiter, solange der Reiter "Felder" nicht erneut gespeichert wird. Ein fest hinterlegter Wert (Konstante) auf einem Verknüpfungsfeld bleibt in jedem Fall unverändert bestehen.

• Anpassung nächtliche Übertragung:
  • Pipelines, die über Verknüpfungsfelder aufeinander verweisen, werden nachts jetzt in der richtigen Reihenfolge übertragen: zuerst die Kunden, und erst nachdem Zoho deren Massenübertragung verarbeitet hat, die Verträge. Dadurch sind die verknüpften Datensätze in Zoho bereits vorhanden, wenn die Verknüpfung gesetzt wird.
  • Die nächtliche Übertragung kann dadurch länger dauern; pro Stufe wird bis zu zwei Stunden auf Zoho gewartet. Läuft diese Zeit ab, startet die nächste Stufe trotzdem; betroffene Datensätze werden in der folgenden Nacht automatisch erneut übertragen. Pipelines ohne Verknüpfungsfelder laufen unverändert wie bisher.
  • Verweist eine Verknüpfung auf einen Datensatz, den die verknüpfte Pipeline nicht überträgt, oder ist das Feld leer, wird die Verknüpfung in Zoho bei der nächtlichen Massenübertragung geleert.
  • Ist der verknüpfte Datensatz noch nicht in Zoho angelegt, weist Zoho nur diesen einen Datensatz zurück. Die Übertragung der übrigen Datensätze läuft weiter, und der zurückgewiesene Datensatz wird in der folgenden Nacht erneut übertragen.

Wird eine verknüpfte Pipeline gelöscht oder archiviert, wird die davon abhängige Pipeline deaktiviert und Sie erhalten die gewohnte E-Mail "Pipeline wurde deaktiviert". Speichern Sie in diesem Fall den Reiter "Felder" erneut und aktivieren Sie die Pipeline wieder.

• Bugfixes:
  • Verknüpfungsfelder mit unpassendem Ameise-Feld: War einem Zoho-Verknüpfungsfeld ein Feld zugeordnet, aus dem sich kein Zoho-Datensatz ermitteln lässt — etwa ein Gesellschafts- oder Sparten-Name —, wies Zoho nicht nur dieses eine Feld zurück, sondern den kompletten Datensatz. Die betroffenen Verträge und Kunden wurden dadurch gar nicht mehr übertragen. Solche Werte werden jetzt weggelassen: der Datensatz geht wieder durch, und das Verknüpfungsfeld bleibt in Zoho unverändert — ein dort bereits gepflegter Wert, etwa aus einer eigenen Zoho-Automatisierung, wird also nicht überschrieben. Ausgelassene Felder werden in der Vorschau und im Reiter "Status" ausgewiesen.
  • Leeren von Verknüpfungen bei der Massenübertragung: Kann eine Spalte für keinen einzigen Datensatz einen gültigen Verweis liefern, wird sie bei der nächtlichen Übertragung ganz weggelassen statt leer übertragen. Andernfalls hätte Zoho das Feld bei jedem Datensatz geleert. Das gilt auch für ein Verknüpfungsfeld mit leerem fest hinterlegten Wert.
  • Ameise-Verbindung: Erneuerte die Ameise den Zugriffs-Token, ohne dabei einen neuen Refresh-Token auszustellen, wurde der neue Token verworfen. Die Verbindung erneuerte sich daraufhin immer wieder vergeblich, bis sie schließlich getrennt wurde und von Hand neu hergestellt werden musste. Der erneuerte Token wird jetzt übernommen.
  • DailyUp-Benachrichtigung: Die Prüfung auf die DailyUp-Lieferung läuft nicht mehr am selben Abend um 22:00 Uhr, sondern am nächsten Morgen um 05:00 Uhr, und sie fragt jetzt "kam in den letzten 24 Stunden eine Datei?" statt auf den Kalendertag zu schauen. Dadurch zählt auch eine Lieferung, die sich bis nach Mitternacht verzögert — bisher konnte in diesem Fall die Meldung "Keine DailyUp-Datei empfangen" verschickt werden, obwohl die Datei angekommen und korrekt verarbeitet war. Da die Meldung ohnehin erst am Arbeitsmorgen gelesen wird, entsteht durch die spätere Prüfung kein Nachteil; sie nennt jetzt zusätzlich den Zeitpunkt, ab dem keine Lieferung mehr eingegangen ist.
  • Angezeigter Lieferzeitpunkt: Der Zeitpunkt einer DailyUp-Lieferung wurde in der Import-Übersicht und im Aktivitätsprotokoll um die Zeitzonen-Differenz verschoben dargestellt — eine um 21:31 Uhr erzeugte Lieferung erschien als 23:31 Uhr. Der Zeitpunkt wird jetzt als echter Zeitpunkt gespeichert und damit in Ihrer eigenen Zeitzone korrekt angezeigt. Bereits vorhandene Lieferungen werden bei der Umstellung mit umgerechnet.
  • Abweichende Vermittlernummer: Wechselte die Lieferung auf eine abweichende Vermittlernummer und danach wieder zurück auf die bisherige, blieb der Import pausiert und der Hinweis nannte eine Vermittlernummer, die gar nicht mehr geliefert wurde. Eine solche überholte Änderung wird jetzt aufgelöst und der Import umgehend wieder aufgenommen.

23.08.2026

• Anpassung CRM-Synchronisierung:
  • Bricht der Abruf eines Zoho-Massenauftrags durch eine kurzzeitige Netzwerkstörung ab, wird er jetzt bis zu dreimal wiederholt (nach 2, 10 und 30 Minuten), statt die gesamte Werkzeug-Aktion sofort abzubrechen. Abgebrochen wird erst, wenn auch der letzte Versuch scheitert. Wiederholt wird ausschließlich der Abruf des Ergebnisses — Datensätze können dadurch nicht doppelt gezählt werden.
  • Dublettenkonflikte beim Anlegen eines Datensatzes im CRM werden zuverlässiger behandelt: Kollidieren mehrere eindeutige Felder gleichzeitig (z.B. E-Mail und Kundennummer), führt das nicht mehr zu einem unbehandelten Fehler. Ein bestehender CRM-Datensatz wird nur noch übernommen, wenn das Identitätsfeld der Pipeline genau diesen einen Datensatz benennt — bisher konnte dabei der Datensatz eines anderen Kunden überschrieben werden. Der Eintrag im Aktivitätsprotokoll nennt jetzt alle kollidierenden Felder statt nur eines.
  • Dublettenkonflikte an einem einzelnen Datensatz lösen keine Störungsmeldung mehr aus. Sie erscheinen weiterhin als fehlgeschlagene Übertragung im Aktivitätsprotokoll und in der Fehler-Zusammenfassung.
  • Die Auswertung eines Massenauftrags bricht nicht mehr mit einem Fehler ab, wenn CRM-Datensatz-IDs numerisch dicht beieinander liegen. Bisher konnte die Rückmeldung dabei einem falschen Datensatz zugeordnet werden und die Aktion mit unvollständigen Zählern stehen bleiben.
  • Ein sehr langer Abbruchgrund konnte dazu führen, dass der Abbruch überhaupt nicht gespeichert wurde. Die betroffene Werkzeug-Aktion galt dann dauerhaft als laufend, wodurch alle weiteren Übertragungen dieser Pipeline unterdrückt wurden. Der Abbruchgrund wird jetzt gekürzt gespeichert, der Abbruch geht nicht mehr verloren.
• Anpassung Werkzeuge:
  • Eine Aktion, die nach einem gescheiterten Versuch doch noch durchläuft, wird jetzt als abgeschlossen angezeigt statt weiterhin als "Abgebrochen".
  • Umgekehrt gilt eine mehrteilige Übertragung nicht mehr als erfolgreich abgeschlossen, wenn ein Teil endgültig gescheitert ist. Der angezeigte Status entspricht damit dem, was tatsächlich im CRM angekommen ist.
  • Der Abbruchgrund steht nicht mehr in der Fortschritts-Spalte, sondern in einer aufklappbaren Detailzeile — die Tabelle wird dadurch nicht mehr über die Bildschirmbreite hinaus gedehnt. Bei wiederholten Aktionen wird die Anzahl der Versuche ausgewiesen, bei gestoppten Aktionen steht "X von Y verarbeitet" statt "erfolgreich".
• Bugfixes:
  • API-Tokens: Die Token-Übersicht ließ sich nicht mehr aufrufen, wenn ein Token eine unbekannte Berechtigung enthielt. Der Wert wird jetzt als "(unbekannt)" ausgewiesen, alle übrigen Tokens bleiben sichtbar.
  • Pipelines: Weist das CRM einen Datensatz in der Vorschau zurück, wird der Fehler jetzt in der Vorschau selbst angezeigt statt einer Fehlerseite.

18.08.2026

• Neue Funktionen:
  • Aktivitätsprotokoll als CSV exportieren: Über den Pfeil neben "Filtern" lässt sich das Aktivitätsprotokoll mit genau den aktuell gesetzten Filtern als CSV herunterladen.
    • Optional können die Spalten "Details" und "Rohdaten" mit exportiert werden.
    • Kleine Exporte werden direkt heruntergeladen. Größere Exporte werden im Hintergrund erzeugt und stehen anschließend unter "Erstellte Exporte anzeigen" zum Download bereit — dort ist auch sichtbar, wer den Export angefordert hat.
    • Sehr große Exporte werden mit einem Hinweis abgelehnt; die gesetzten Filter bleiben erhalten, damit die Auswahl eingegrenzt werden kann.
    • Zeitangaben werden in der Zeitzone des anfordernden Benutzers ausgegeben.
  • Quelle-Filter mit Suche: Der Filter "Quelle" im Aktivitätsprotokoll ist jetzt ein Suchfeld statt einer Auswahlliste. Bisher standen nur Quellen zur Auswahl, die in den letzten sieben Tagen aktiv waren — jetzt sind auch länger zurückliegende Quellen auffindbar.
  • Vertragsprodukte (API & MCP): Neue Endpunkte für Vertragsprodukte: Spartentemplate abrufen, Produktkomponenten eines Vertrags lesen und ändern sowie die KFZ-Produktstruktur (Halter/Fahrer) anlegen. Nicht jede Sparte führt Detaildaten — in dem Fall meldet die Schnittstelle das ausdrücklich zurück.
  • Obervermittler in Pipeline-Regeln: Der neue Operator "ist einer von (inkl. Untervermittler)" wählt einen Obervermittler samt aller darunter liegenden Vermittler aus. Die Auswahlliste zeigt die Vermittler-Hierarchie jetzt als eingerückten Baum statt als flache, nach Vermittlernummer sortierte Liste. Für Auswahlfelder stehen zusätzlich "ist einer von" und "ist keiner von" zur Verfügung.
    • Vermittler, deren Obervermittler in den Daten fehlt, werden auf oberster Ebene angezeigt.
  • Suche und Filter in der Pipeline-Übersicht: Die Pipeline-Übersicht hat jetzt eine Suche nach dem Pipeline-Namen sowie Filter nach CRM, Ameise-Objekt und Status. Die Filter lassen sich kombinieren und bleiben beim Wechsel in die Archiv-Ansicht erhalten.
  • Werkzeug-Katalog mit Suche (MCP, optional): Für ein Token lässt sich einstellen, dass der MCP-Server die rund 85 Werkzeuge nicht mehr als vollständige Liste ausliefert, sondern nur noch search_tools und execute_tools. Das hält den Kontext von KI-Clients klein und verbessert die Trefferquote bei der Werkzeugauswahl. Die Einstellung steht in der Token-Verwaltung unter "Optionen" und erscheint, sobald eine MCP-Berechtigung ausgewählt ist.
  • Bedienung ohne Maus: Die Mehrfachauswahl-Filter im Aktivitätsprotokoll und in der Pipeline-Übersicht sowie die Navigations-Schalter lassen sich jetzt vollständig per Tastatur bedienen und melden ihren Zustand an Screenreader.

Hinweis für externe MCP-Clients: Bestehende Tokens erhalten weiterhin die vollständige Werkzeug-Liste. Die Option sollte nur für Clients gesetzt werden, die Werkzeuge nicht namentlich fest hinterlegen oder einschränken. Die Berechtigungen je Token gelten in beiden Fällen unverändert — Werkzeuge, für die ein Token keine Berechtigung besitzt, erscheinen auch in der Suche nicht.

• Anpassung Aktivitätsprotokoll:
  • Bei Übertragungen zum CRM wird jetzt durchgängig die verursachende Pipeline als Quelle angezeigt — bei erfolgreichen wie bei fehlgeschlagenen Übertragungen. Bisher stand dort je nach Auslöser der Daily-UP-Import. Wodurch die Übertragung angestoßen wurde, steht weiterhin in den Details unter "Ausgelöst durch".
  • Eine manuelle Übertragung über "An CRM übertragen" weist jetzt unter "Ausgelöst durch" aus, wer sie ausgelöst hat — auch bei erfolgreicher Übertragung. Bisher wurde dafür niemand festgehalten.
  • Pipelines, Daily-UP-Importe und Werkzeug-Aktionen sind jetzt direkt verlinkt, ebenso der Eintrag unter "Ausgelöst durch". Archivierte Pipelines bleiben ohne Link, da ihre Detailseite nicht mehr aufrufbar ist.
  • Vermittler werden in Pipeline-Regeln, Feld-Zuordnungen und im Aktivitätsprotokoll jetzt mit Namen und Nummer angezeigt statt nur mit der Nummer. Im Aktivitätsprotokoll wird der Name bei langen Namen gekürzt, die Nummer bleibt dabei vollständig sichtbar.

Wichtig: Die Statistiken auf der Pipeline-Statusseite enthalten dadurch erstmals auch die Übertragungen aus dem Daily-UP-Import. Zahlen vor dem 18.08.2026 sind unvollständig und lassen sich nachträglich nicht korrigieren.

• Anpassung CRM-Synchronisierung:
  • Datensätze, deren Übertragung dauerhaft am selben Grund scheitert (z.B. ein Dublettenkonflikt oder ein ungültiger Wert), werden jetzt vorgemerkt und in den folgenden nächtlichen Übertragungen übersprungen, statt jede Nacht erneut zu scheitern. Die Sperre wird automatisch aufgehoben, sobald sich der auslösende Wert ändert oder der Datensatz im CRM ankommt.
    • Da gesperrte Datensätze nicht mehr versucht werden, tauchen sie auch nicht mehr in den nächtlichen Fehlermeldungen auf. Stattdessen informiert eine wöchentliche Zusammenfassung (montags) über den bestehenden Rückstand. Deaktivierte Pipelines und Pipelines mit deaktivierter CRM-Verbindung bleiben darin unberücksichtigt.
    • Gleichzeitig werden Datensätze, die noch nie im CRM angelegt wurden, wieder in die nächtliche Übertragung aufgenommen. Bisher liegen gebliebene Datensätze erhalten so einen neuen Versuch.
  • Die Fehlermeldung zu einer Synchronisierung nennt jetzt die häufigsten Fehlerursachen, statt nur deren Anzahl zu melden.
  • Einzelne vom CRM nicht verarbeitete Datensätze brechen nicht mehr die gesamte Teilübertragung ab. Feldbezogene Fehler an ansonsten geschriebenen Datensätzen werden jetzt mitgezählt.
  • Eine einzelne durch das CRM ausgebremste Anmeldung deaktiviert nicht mehr sofort die gesamte CRM-Verbindung eines Mandanten.
  • Ein Fehler wurde behoben, durch den eine Aktualisierung den falschen Datensatz treffen und damit spätere Änderungen an den falschen CRM-Datensatz senden konnte.
• Bugfixes:
  • Pipelines: Die Zuordnung eines Ja/Nein-Feldes aus dem CRM führte zu einem Fehler in der Umwandlung.
  • Pipeline-Editor: Beim Leeren eines Suchfeldes gingen Regelwerte verloren oder wurden verfälscht. Außerdem verdrängten die Feld- und Operator-Auswahl nicht mehr das Eingabefeld für den Wert.
• Sicherheit:
  • Exporte von Kunden- und Vertragsdaten (CSV und Excel) geben Zellinhalte nicht mehr als ausführbare Tabellenformeln aus. Ein Kundenname wie "=1+1" wurde bisher als Formel in die Datei geschrieben.
  • Formularfelder werden jetzt ausschließlich aus dem Request-Body gelesen. Bisher konnte ein Query-Parameter ein Feld setzen, das der Aufrufer im Body ausgelassen hatte — beispielsweise konnte ?enabled=1 einen Webhook aktivieren oder ?anrede_id=... bei einer Änderung den Kommunikationskontext neu angelegter Kommunikationen umstellen.
  • Zwei Stellen wurden behoben, an denen im Quelle-Filter des Aktivitätsprotokolls der Benutzer-, Firmen- oder Token-Name eines anderen Mandanten angezeigt werden konnte.

Wichtig für API-Nutzer: Felder, die bisher als Query-Parameter (?feld=wert) übergeben wurden, werden nicht mehr ausgewertet und müssen in den Request-Body wandern. Ausgenommen bleiben die dokumentierten Query-Parameter mitteilung-benutzername, mitteilung-passwort-link und mitteilung-erstinfo-unterbinden an den Kunden-Endpunkten sowie die Status- und Löschabfrage unter webhook/managed.

13.08.2026

1. Bugfixes:
   
1. Webhooks: Änderungen an Kunden-Detailfeldern aus dem Daily-UP-Import lösen wieder Webhooks aus. Seit der Umstellung auf die gebündelte Verarbeitung wurden die Werte zwar korrekt importiert, die zugehörigen Kunden-Detail-Webhooks aber nicht mehr versendet.

07.08.2026

16.07.2026

1. Sicherheit: Umfassende Härtung von Sicherheit und Zugriffskontrolle.

Hinweis für API-/MCP-Nutzer: Auf bestimmte Vermittler eingeschränkte Zugriffstoken sind jetzt durchgängig auf ihre zugelassenen Vermittler begrenzt. Zugriffe auf Kunden, Verträge, Schäden oder Aufgaben außerhalb des erlaubten Bereichs werden abgewiesen.

1. Neue Funktionen:
   
1. Prompt-Vervollständigung (MCP): Argumente von MCP-Prompts (z.B. die Kontaktart) werden beim Tippen automatisch mit passenden Vorschlägen vervollständigt. (Wenn der Dienst den Sie verwenden das unterstützt)
   
2. Anpassung CRM-Synchronisierung:
   
1. Bestimmte Übertragungsfehler betreffen jetzt nur noch den einzelnen Datensatz statt die gesamte Pipeline (z.B. bei ungültigen Feldwerten).
   
2. Hängengebliebene Massen-Übertragungen werden automatisch wieder aufgenommen.
   
3. Anpassung Import & Export:
   
1. Exporte bleiben auch bei gleichzeitigen Änderungen vollständig und konsistent (keine übersprungenen oder doppelten Zeilen).
   
2. Fehlgeschlagene Exporte bleiben nicht mehr dauerhaft hängen.
   
3. Massen-CSV-Dateien für Zoho sollten jetzt noch besser funktionieren.
   
4. Beim Import werden doppelte Kommunikations-Einträge innerhalb eines Datei-Stapels entfernt und hängengebliebene Verarbeitungssperren automatisch gelöst.
   
4. Anpassung API & MCP:
   
1. Konfliktbehandlung (API & MCP): Beim Anlegen oder Ändern von Kunden und Verträgen wird bei einem Konflikt jetzt eine strukturierte Rückmeldung geliefert (inkl. Anzahl und Ameise-IDs der übereinstimmenden Datensätze), statt die übermittelten Daten zu verwerfen.
   
2. MCP-Schreibvorgänge werden im Aktivitätsprotokoll dem verwendeten Zugriffstoken als Verursacher zugeordnet.
   
5. Bugfixes:
   
1. Dashboard: Diagramme werden wieder zuverlässig dargestellt.
   
2. Webhooks: Eingehende (unauthentifizierte) Webhook-Endpunkte sind jetzt pro Mandant mit einem Rate-Limit gegen Überlastung geschützt.
   
3. Alte Export- und Zoho-Massen-CSV-Dateien werden nach einer Aufbewahrungsfrist automatisch entfernt.
   

06.07.2026

1. Neue Funktionen:
   
1. Fehler-Benachrichtigungen: Neuer Verwaltungsbereich, um festzulegen, wer bei Problemen per E-Mail informiert wird
   
1. Empfänger mit E-Mail-Adresse (und optional Name) hinzufügen und pro Empfänger auswählen, welche Benachrichtigungsarten sie erhalten
   
2. Externe Empfänger bestätigen ihre Adresse über einen signierten Link (7 Tage gültig); Empfänger, die bereits Benutzer des Systems sind, werden automatisch bestätigt
   
3. Bestätigungsstatus einsehen und die Bestätigungs-E-Mail bei Bedarf erneut versenden
   
4. Verfügbare Benachrichtigungen:
   
1. Fehler beim Senden an das CRM (Sammelmeldung) und Fehler beim Empfang aus dem CRM (Sammelmeldung): Übertragungsfehler werden nach Richtung getrennt gemeldet und können je Richtung einzeln abonniert werden. Fehler werden gebündelt statt einzeln versendet — aufgeschlüsselt nach Pipeline und Anzahl betroffener Datensätze. Jede Richtung hat eine eigene Ruhephase; in dieser Zeit aufgetretene Fehler werden in der nächsten Meldung zusammengefasst nachgereicht.
   
2. Manuelle Synchronisierung fehlgeschlagen: Bericht, wenn ein manuell gestarteter Lauf mit Fehlern endet (Anzahl fehlgeschlagener und gesamter Datensätze, Link zum Aktivitätsprotokoll)
   
3. Automatische Massen-Übertragung fehlgeschlagen: einmalige Meldung, wenn eine automatische Bulk-Synchronisierung mit Fehlern abschließt
   
4. DailyUp nicht geliefert: Meldung, wenn abends keine erwartete DailyUp-Datei von der Ameise eingegangen ist
   

27.05.2026

1. Bugfixes:
   
1. Kunden-Kommunikation: E-Mail und Telefon werden beim ersten Push an das CRM nicht mehr fälschlich geleert
   

02.04.2026

1. Bugfixes:
   
1. DailyUp-Import: Stornogründe werden jetzt auch anhand ihrer Bezeichnung korrekt zugeordnet (nicht nur per ID)
   

1. Neue Funktionen:
   
1. Aufgaben / Tasks (API & MCP): Neue Schnittstelle zur Verwaltung von Aufgaben aus der Ameise
   
1. Aufgaben auflisten, erstellen, bearbeiten, löschen und Status ändern
   
2. Verknüpfung mit Kunden und Verträgen möglich
   
2. Schadensfälle / Claims (API & MCP): Neue Schnittstelle zur Verwaltung von Schadensfällen
   
1. Schadensfälle nach Kunde oder Vertrag auflisten, erstellen, bearbeiten und löschen
   
3. Kunden-Notizen (API & MCP): Notizen zu Kunden auflisten, erstellen, bearbeiten und löschen
4. Kunden-Beziehungen (API & MCP): Beziehungen zwischen Kunden auflisten, erstellen und löschen
5. Weitere Kunden-Adressen (API & MCP): Zusätzliche Adressen eines Kunden auflisten, erstellen, bearbeiten und löschen
6. Kunden-Benachrichtigungen (API & MCP): Benachrichtigungen an Kunden versenden
7. Vertrags-Bankverbindung (API & MCP): Bankverbindung eines Vertrags auslesen und ändern
8. Daten-Export (MCP): Export von Kunden- und Vertragsdaten als CSV, XLSX oder PDF
   
1. Kleine Exporte (<1.000 Datensätze) werden sofort bereitgestellt
   
2. Größere Exporte werden im Hintergrund verarbeitet mit Status-Abfrage
   
9. Erweiterte Kundensuche (API & MCP): Mehrteilige Namenssuche unterstützt jetzt 2- und 3-Wort-Kombinationen in beiden Reihenfolgen (z.B. "Max Mustermann" findet auch "Mustermann, Max")
   
10. MCP-Werkzeuge auf Deutsch: Alle MCP-Werkzeug-Beschreibungen wurden auf Deutsch übersetzt für bessere Verständlichkeit bei deutschsprachigen KI-Assistenten
    
11. Ameise OAuth-Berechtigungen: Das Dashboard zeigt jetzt eine Warnung an, wenn die Ameise-Verbindung mit veralteten Berechtigungen arbeitet und eine Neuverbindung empfohlen wird
    
12. DailyUp Bulk-Übertragung: Wenn ein DailyUp-Import viele Datensätze betrifft, werden diese automatisch gebündelt über die Zoho Bulk Write API übertragen statt einzeln — das spart API-Aufrufe und beschleunigt die Synchronisation
    
13. Pipeline-Verbindungstest: Pipelines können jetzt mit einem vollständigen Testlauf (Anlegen → Aktualisieren → Upsert → Löschen) gegen das CRM geprüft werden
14. PerDu-Kennzeichen: Das "Per Du"-Kennzeichen wird jetzt bei der Datenübertragung an die Ameise mitgeliefert
15. Qonekto Markendesign: Überarbeitetes Farbschema und neue Favicons im gesamten System
    
2. Bugfixes:
1. DailyUp-Import: Felder wie "Per Du" und "Verstorben" werden korrekt als Ganzzahl übernommen; ungültige Werte in Zahlen-/Dezimalfeldern verursachen keine Fehler mehr
2. Eingaben in den Feldern "Betreff" und "Dateiname" dürfen keine Zeilenumbrüche mehr enthalten
3. Sonstige Änderungen:
   
1. Geteilte Validierungsregeln für konsistentere Fehlermeldungen zwischen API und MCP
   
2. Einschränkung der erlaubten Status-Werte bei Vertragserstellung zur Vermeidung ungültiger Einträge
   

02.03.2026

1. Neue Funktionen:
   
1. Aktivitäts-Log Aufbewahrung: Aktivitätsdaten werden ab sofort für 1 Jahr aufbewahrt. Ältere Aktivitätsdaten wurden gelöscht.
   Ein entsprechender Hinweis wird im Aktivitäts-Log und in der Pipeline-Statistik angezeigt.
2. Bugfixes:
   
1. Pipeline-Übertragung: Fehler bei der Übertragung von Datums-Feldern an numerische CRM-Felder behoben
   
2. Pipeline-Transformation: Fehler bei der Zuordnung von leeren oder nicht-textuellen Werten behoben
   
3. Kunden-Tags: Sonderzeichen und Großbuchstaben-Umlaute (Ä, Ö, Ü) werden jetzt korrekt in Tags unterstützt
   
4. Kunden-Filter: Leere und null-Werte in Kommunikationsfeldern werden jetzt korrekt behandelt

1. Neue Funktionen:
   
1. Neue Vertragsfelder aus DailyUp verfügbar: Tarifbeitrag, Risiko-Zusatz, Änderungsdatum, Änderungsgrund, Letzte Änderung, Stornogrund
   
2. Neue Vermittler-Felder aus DailyUp verfügbar (u.a. IBAN, erweiterte Adressdaten)
   
3. Vertrags-Endpunkte (MCP): Neue Felder in der Ausgabe ergänzt

1. Neue Funktionen:
   
1. Vermittler-ID wird jetzt bei der Erstellung von Verträgen an die Ameise mitgeliefert

1. Neue Funktionen:
   
1. MCP Server (Model Context Protocol): Neue Schnittstelle für KI-Assistenten wie Claude
   
1. Direkter Zugriff auf Kunden-, Vertrags- und Archivdaten für KI-Assistenten
   
2. Vorgefertigte Workflows (Prompts) für häufige Aufgaben
   
3. Unterstützt alle CRUD-Operationen (Erstellen, Lesen, Aktualisieren)
   
4. Gecachte Referenzdaten-Ressourcen für bessere Performance
   
5. Kunden-Archiv (MCP): Neue Werkzeuge zum Verwalten von Kunden-Archiven
   
1. Archiv-Einträge auslesen und hinzufügen
   
2. Dokumenten-Upload unterstützt (PDF, JPEG, PNG, TIFF, DOCX, XLSX, max. 5 MB)
   
3. Erfassung von Kommunikationen (E-Mail, Telefon, Brief, persönlich, etc.)
   
4. Tags und Zuordnung zu Verträgen oder Versicherungssparten möglich
   
6. Kunden-Archiv Download (API & MCP): Download von Archiv-Dokumenten über signierte URLs
   
1. Zeitlich begrenzte, sichere Download-Links für Archiv-Dokumente
   
2. Automatische Datei-Bereitstellung über Ameise API
   
3. Tenant-spezifische Zugriffskontrolle
   
7. Analytics & Business Intelligence (MCP): Leistungsstarke Analyse-Werkzeuge für Kunden und Verträge
   
1. Zählung (count): Anzahl der Kunden/Verträge nach Filterkriterien
   
2. Durchschnitt (average): Berechnung von Durchschnittswerten (z.B. Durchschnittsalter, Durchschnittsprämie)
   
3. Gruppierung (group_by): Verteilung nach Feldern (z.B. nach PLZ, Versicherungssparte)
   
4. Spezialfilter: Kunden mit/ohne bestimmte Versicherungsarten, PLZ-Präfix-Suche
   
8. Feld-Auswahl / Sparse Fieldsets (API & MCP): Möglichkeit zur gezielten Auswahl von Feldern in Antworten
   
1. Reduziert Antwortgröße um 70-95% bei gezielter Auswahl
   
2. Unterstützt verschachtelte Felder mit Punkt-Notation (z.B. "kommunikation.email")
   
3. Verfügbar für alle Listen-, Such- und Detail-Endpunkte
   
9. Verbesserte Fehlermeldungen (MCP): Erweiterte Fehlerbehandlung mit hilfreichen Vorschlägen
   
1. Klare Fehlerbeschreibungen mit Lösungshinweisen
   
2. Vorschläge für alternative Werkzeuge bei bestimmten Fehlern
   
3. Auflistung verfügbarer Felder bei ungültigen Feldangaben
   
2. Vermittler-Einschränkungen für API-Tokens (API & MCP): API-Tokens können jetzt auf bestimmte Vermittler beschränkt werden
1. Tokens mit Vermittler-Einschränkungen sehen nur Kunden und Verträge der zugewiesenen Vermittler
2. Bei Erstellung von Kunden/Verträgen muss eine gültige Vermittler-ID aus dem erlaubten Bereich angegeben werden
3. ListBrokers zeigt nur die für das Token freigegebenen Vermittler an
4. Konfiguration über das API-Token-Verwaltungs-Interface
3. Bereitstellung n8n Node Operationen via Community Node: n8n-nodes-qonekto
   
4. Erweiterung Make um Trigger
   
5. Webhooks wurden umgearbeitet, sodass diese jetzt mit Grundlage des Aktivitäts-Logs arbeiten und ausgelöst werden wenn eine Aktivität mit der gewünschten Aktion und Objekt-Typ.
   
6. Für Webhooks kann jetzt ein Test ausgelöst werden.
   
2. Sonstige Änderungen:
   
1. Umstellung auf multibyte-sichere String-Funktionen für bessere Unterstützung von Umlauten und Sonderzeichen
   
2. Performance-Optimierungen bei Datenbankabfragen
   
3. Verbesserte Benachrichtigungen: Mandanten werden jetzt informiert, wenn Webhooks nach wiederholten Fehlern automatisch deaktiviert werden

Aufgrund der grundsätzlichen Umstellung der Webhooks wurden alle bestehenden Webhooks gelöscht.

22.10.2025

1. Bugfixes:
   
1. Verbesserte Fehlerausgabe bei ungültigen JSON-Eingaben: Originalwerte werden jetzt in Fehlermeldungen angezeigt
   

21.10.2025

1. Bugfixes:
   
1. Validierung von Query-Parametern in Kunden- und Vertrags-Endpunkten verbessert
   

20.10.2025

1. Bugfixes:
   
1. Behandlung leerer vermittler_id Werte korrigiert
   

19.10.2025

1. Neue Funktionen:
   
1. API-Token Verwaltung: Erweiterte Sicherheitsfunktionen für API-Tokens
   
1. Token-Berechtigungen: Schreibgeschützte und Schreibzugriff-Token
   
2. IP-Einschränkungen: Tokens können auf bestimmte IP-Adressen oder IP-Bereiche beschränkt werden
   
3. Regions-Einschränkungen: Zugriff kann auf bestimmte Länder/Regionen begrenzt werden
   
4. Ablaufdatum: Tokens können mit einem automatischen Ablaufdatum versehen werden
   
5. Beispiel IP-Einschränkungen: 192.168.1.0/24 für ein Subnetz oder 203.0.113.5 für eine einzelne IP
   
2. Bugfixes:
   
1. Validierung von Query-Parametern in Kunden- und Vertrags-Endpunkten verbessert
   
2. Behandlung leerer vermittler_id Werte korrigiert
   
3. Verbesserte Fehlerausgabe bei ungültigen JSON-Eingaben
   

18.10.2025

1. Neue Funktionen:
   
1. Vertrags-Suche erweitert: Suche nach Verträgen jetzt auch nach versichertem Risiko (risiko) möglich
   
2. Anpassung Verträge:
   
1. Filter-Parameter _skip und _limit zur API-Dokumentation hinzugefügt
   
2. Fehlende Filter-Parameter für Verträge nachgetragen (z.B. zusätzliche Suchfelder)
   
3. Anpassung Pipelines:
   
1. Pipelines werden bei bestimmten weiteren Zoho-Fehlercodes automatisch deaktiviert um Fehlerflut zu vermeiden
   

13.10.2025

1. Neue Funktionen:
   
1. Verträge-Tag können via API ausgelesen, und begrenzt erstellt werden.
   
2. Kunde Upsert Validierung wurde erweitert um Fehler zu verhindern.