Kurze Antwort: In der V17-Architektur von Mikro müssen Sie Ihre Integration jetzt nicht mehr auf direktem SQL-Zugriff, sondern auf der offiziellen Mikro Desktop API aufbauen. Die von Integratoren am Markt verbreitete Formulierung „In V17 wurde der direkte Datenbankzugriff geschlossen, das System ist vollständig API-basiert geworden" ist zwar eine griffige Zusammenfassung, trifft es aber nicht ganz: Mikros eigene offizielle Dokumentation sagt ausdrücklich, dass Tabellenfelder, die nicht im API-JSON enthalten sind, weiterhin direkt über ihre DB-Namen verwendet werden können. Die korrekte Lesart lautet also: Mit V17 ist die offizielle API zum primären und unterstützten Integrationskanal geworden; eine dokumentierte Ausnahme des „Zugriffs über den DB-Namen" besteht weiterhin für Felder, die die API nicht ausgibt. Was sollten Sie nun tun? Drei Schritte: (1) inventarisieren Sie alle vorhandenen SQL-Lese-/Schreibpunkte Spalte für Spalte, (2) ordnen Sie jedes Feld der Frage zu, ob „ein API-Endpunkt existiert oder ein DB-Namen-Fallback nötig ist", (3) beantragen Sie über das offizielle Entwicklerportal einen API-Key, lassen Sie den neuen Ablauf parallel laufen und testen ihn, und führen Sie anschließend den Umstieg (Cutover) durch. In diesem Leitfaden erläutern wir diesen Umstieg Schritt für Schritt, ohne erfundene Genauigkeit und gestützt auf die offizielle Mikro-Dokumentation.

Als in Sakarya ansässiges B2B-/White-Label-Softwareengineering-Unternehmen betreuen wir diesen Umstieg für Integrationen, die im Bereich E-Commerce, Individualsoftware und Buchhaltung von Mikro abhängen. Nachfolgend teilen wir sowohl die Logik hinter der Entscheidung als auch das konkrete Playbook, das wir in der Praxis anwenden. Jede Aussage, die im Zusammenhang mit Daten und Ports „sicher" wirkt, haben wir dort belassen, wo wir sie auf eine offizielle Quelle stützen, und dort, wo es sich um eine Integrator-Interpretation handelt, dies ausdrücklich gekennzeichnet.

Was genau hat sich geändert?

Mikro hat ein offizielles Entwicklerportal für seine Desktop-Produkte veröffentlicht: apidocs.mikro.com.tr. Der Slogan des Portals lautet „Entwickeln, Testen, Ausrollen — Mikro API-Integrationsleitfaden", und die Zielgruppe wird ausdrücklich so definiert: Mikro-Yazılım-Kunden, Mikro-Yazılım-Geschäftspartner und Drittanbieter-Lösungsentwickler. Diese API ist also nicht nur für Vertriebspartner gedacht, sondern auch der offizielle Kanal für die eigenen Teams der Kunden und für unabhängige Softwarehäuser.

Auch die technische Natur der API ist eindeutig: REST/JSON über HTTP. Neben Leitfäden mit den Titeln „JSON- und REST-API-Grundlagen", „HTTP-Protokoll und Statuscodes" sowie „Endpunkt-Nutzung" bietet das offizielle Portal herunterladbare offizielle Postman-Collections sowohl für V17 als auch für V16 an („Aktuelle Postman Collection (V17)" und „(V16)"). Diese Collections sind der offizielle Ausgangspunkt Ihrer Testphase.

Kritische Feinabstimmung: Zu sagen „V17 hat jeden direkten Datenbankzugriff entfernt" ist falsch. Laut offizieller FAQ gilt: „Tabellenfelder, die nicht im API-JSON enthalten sind, können ebenfalls direkt über ihre DB-Namen verwendet werden." Der korrekte Rahmen lautet: Die offizielle API ist nun der verpflichtende und unterstützte primäre Kanal, während der DB-Name eine dokumentierte Ausnahme für Felder ist, die die API nicht ausgibt.

Warum wurde der direkte DB-Zugriff in den Hintergrund gedrängt? (die Logik der Entscheidung)

Integrator-Blogs am Markt (z. B. ozgurguler.net, mikrodestek.net) fassen diese Änderung mit den Worten zusammen: „Mikro hat ab V17 den direkten Datenbankzugriff geschlossen und ist auf ein vollständig API-basiertes System umgestiegen." Dies sollte man nicht als offiziellen Mikro-Satz, sondern als Integrator-Interpretation weitergeben; denn wir konnten diese Formulierung wortwörtlich nicht in Mikros eigenen Quellen finden, und die oben genannte DB-Namen-Ausnahme relativiert diese absolute Aussage. Dennoch ist die technische Logik, weshalb ein ERP-Hersteller statt direktem SQL eine kontrollierte API-Schicht durchsetzt, klar:

  • Stabilität und Schema-Unabhängigkeit: Direktes SQL bindet sich eng an die Tabellen- und Spaltenstruktur. Ändert der Hersteller in einer Version das Schema, brechen Ihre Abfragen stillschweigend. Eine API-Schicht setzt einen Vertrag zwischen dem internen Schema und dem externen Konsumenten; selbst wenn sich die Struktur intern ändert, kann der Endpunkt-Vertrag erhalten bleiben.
  • Sicherheit und Berechtigungsoberfläche: Ihrer Anwendung direkte Datenbank-Zugangsdaten (Connection String) zu geben, ist die breiteste Berechtigungsoberfläche. Der Zugriff über die API delegiert die Authentifizierung an Mikros eigenen Sitzungs-/Berechtigungsmechanismus; der Zugriff lässt sich auf Endpunkt-Ebene begrenzen.
  • Support und Vorhersehbarkeit: Der Hersteller kann bei direktem SQL nicht wissen, was Sie lesen/schreiben; da Geschäftsregeln umgangen werden können, entsteht ein Risiko für die Datenintegrität. Über die API durchgeführte Vorgänge sind definiert, versioniert und supportfähig. Tatsächlich veröffentlicht Mikro ein datiertes V17-API-Changelog — der älteste Eintrag, den wir sehen konnten, ist [17.03a] – 14.04.2025, der neueste [17.07b] – 05.08.2026. Dies ist der Beweis, dass die API aktiv versioniert wird und sich weiterentwickelt.

Wer ist betroffen?

Jede Integration, die sich direkt mit der Mikro-Datenbank verbindet, ist von diesem Umstieg betroffen. Die drei Gruppen, denen wir in der Praxis am häufigsten begegnen:

  • E-Commerce-Integrationen: Shops, die die Synchronisation von Bestand, Preis, Debitoren und Aufträgen zwischen Website/Marktplatz über SQL abwickeln. Schreibvorgänge wie Bestandsabbuchung, Rechnungs-/Lieferscheinerstellung und Auftragsübertragung sind auf dieser Seite die kritischsten Risiken.
  • Individualsoftware / interne Projekte: Interne Entwicklungen, die Mikro als einzige Quelle der Wahrheit (Source of Truth) nutzen, wie Produktionsverfolgung, Außendienst-Apps und B2B-Händlerportale. Für diese Gruppe läuft die API-Key-Lizenzierung manuell (siehe unten).
  • Buchhaltungs- und Reporting-Integrationen: Debitoren-Abstimmung, E-Rechnungs-/E-Archiv-Brücken, BI-/Report-Dashboards und wiederkehrende Exporte. Obwohl die meisten „nur lesend" sind, ist dies die Gruppe, die am stärksten in direkte Tabellenabfragen verwoben ist.

Ob E-Commerce- und E-Rechnungs-Abläufe auf der Mikro-Seite mit einem fertigen Modul oder mit einer individuellen API-Integration gelöst werden, ist für sich genommen eine eigene Entscheidung; diese haben wir in einem separaten Beitrag behandelt: E-Commerce + ERP + E-Rechnung-Integration: fertig oder individuelle API?

Umstiegs-Playbook: von SQL-Lesevorgängen zu API-Endpunkten

Die folgenden Schritte sind eine redaktionelle Empfehlung, die wir auf den von Mikro dokumentierten Fakten aufbauen — Punkte wie Parallelbetrieb und Rollback sind kein von Mikro vorgeschriebenes Verfahren, sondern Standard-Best-Practice der Integration.

1) Feldinventar: ordnen Sie jede SQL-Spalte zu

Der erste und am häufigsten übersprungene Schritt: Ermitteln Sie jede Tabelle und jede Spalte, die Ihre bestehende Integration berührt. Wählen Sie dann für jedes Feld einen von zwei Wegen:

  • Wird das Feld im API-JSON ausgegeben → lesen Sie es aus der Antwort des entsprechenden REST-Endpunkts.
  • Ist das Feld nicht im API-JSON enthalten → es kann, wie in der offiziellen FAQ angegeben, direkt über den DB-Namen referenziert werden. Dies ist ein wichtiger Ausweg, der den Druck mildert, „alles auf einmal auf die API umstellen zu müssen".
  • Existiert es weder als Endpunkt noch als zugängliches Feld → eröffnen Sie über das Programm-API-Antragsformular eine Anfrage für eine neue Tabelle/einen neuen Endpunkt (Mikro sagt: „Für neue Tabellenanfragen: API-Antragsformular").

Umstiege, die ohne dieses Inventar durchgeführt werden, fliegen im Livebetrieb mit „Feld fehlt"-Fehlern um die Ohren. Die Spalte-für-Spalte-Zuordnung ist der anstrengendste, aber entscheidendste Schritt des Umstiegs.

2) Authentifizierung und Antrag

Zuerst der Zugriff: Integratoren füllen das Programm-API-Antragsformular aus. Laut offiziellem Leitfaden werden API-Keys Nutzern einer Vertikallösung automatisch zugewiesen; für interne Software wird eine manuelle Lizenz erteilt. (Die in manchen Integrator-Blogs beschriebenen Schritte wie „detaillierte E-Mail-Frage-Antwort-Prüfung und Weiterleitung an die Passwort-Abteilung" sind in dieser Form nicht in der offiziellen Dokumentation belegt; die offizielle Quelle enthält lediglich das Formular, die Lizenzierungs-Unterscheidung sowie die Kontaktadressen.)

Das Authentifizierungsmodell ist kein OAuth — das sagen wir klar. Das Modell basiert auf API-Key + Sitzung/Login. Laut offiziellem Leitfaden werden bei jeder Anfrage folgende Informationen verwendet:

Feld Wofür es dient
ApiKey Der per Antrag erhaltene Schlüssel; wird im JSON-Body gesendet. Bei falschem Wert wird der Fehler „Ungültiger API-Key" zurückgegeben.
FirmaKodu Firmencode.
CalismaYili Geschäftsjahr.
KullaniciKodu Benutzercode.
Sifre Passwort; laut offiziellem Leitfaden berechnet als Datum + Passwort → MD5-Hash.

Bei der Sitzungsverwaltung gibt es einen Versionsunterschied. Die V1-Methoden öffnen zunächst mit APILogin eine Sitzung (die Adresse auf der offiziellen Installationsseite: POST http://localhost:8094/Api/APIMethods/APILogin, im Body FirmaKodu, CalismaYili, ApiKey, KullaniciKodu, Sifre). Die V2/V3-Methoden hingegen senden die Benutzerdaten direkt im JSON jedes Endpunkts und führen nach Abschluss des Vorgangs einen automatischen Logout durch. Berücksichtigen Sie diese Unterscheidung von Anfang an beim Aufbau Ihrer Architektur (persistente Sitzung oder auf Anfrage).

3) Installation und Port-Einstellungen

Die API wird über die Option „Server" auf der Seite der Versionsaktualisierungen installiert und registriert einen Windows-Dienst namens Mikro Desktop API. Der Dienst läuft unter dem Konto NT SERVICE\MikroDesktopAPIContainer; die Port-Parameter werden unter HKLM\SYSTEM\CurrentControlSet\Services\MikroDesktopAPIContainer\Parameters vorgehalten. Möchten Sie den Port ändern, stoppen Sie den Dienst, bearbeiten ihn per regedit (Decimal Base) und geben den Port anschließend in der Windows-Firewall frei.

Die Standard-Dienstports unterscheiden sich je nach Version: 8094 für V17, 8084 für V16. Dies sind jeweils Standard-Ports, die sich über die Registry ändern lassen; statt „Mikro hat den Port von 8084 auf 8094 geändert" ist es also korrekter zu sagen „Der V16-Standard ist 8084, der V17-Standard ist 8094". Falls Sie diesen Port in Ihrer Umgebung angepasst haben, richten Sie Ihre Aufrufadressen entsprechend ein.

4) Test: die offizielle Postman-Collection

Verifizieren Sie die Aufrufe vor dem Programmieren manuell. Laden Sie Mikros offizielles Paket Postman Collection (V17) herunter und führen Sie die in Ihrem Inventar markierten Endpunkte mit Ihren Zugangsdaten aus. Vergleichen Sie die erwarteten Antworten mit Ihren bestehenden SQL-Ausgaben; gehen Sie nicht live, bis eine Feld-für-Feld-Übereinstimmung erreicht ist. In dieser Phase ist der offizielle technische Supportkanal [email protected], für Fragen rund um API-Key/Partner hingegen die Adresse [email protected].

5) Parallelbetrieb und Rollback

Der risikominimierende Schritt: Lassen Sie den neuen API-basierten Ablauf neben dem alten SQL-Ablauf laufen. Lassen Sie über einen bestimmten Zeitraum beide Wege dieselben Daten (Lese-/Schreibvorgänge) erzeugen; vergleichen Sie die Ergebnisse automatisch (Reconciliation). Gibt es keine Abweichung, steigt das Vertrauen. Halten Sie in diesem Zeitraum Ihren Rollback-Plan bereit: Mit einem Feature-Flag sollten Sie per Klick zum alten Ablauf zurückkehren können. Dieser Ansatz von Parallelbetrieb/Rollback ist keine Anweisung von Mikro, sondern das von uns empfohlene Standard-Sicherheitsnetz der Integration.

6) Cutover und Versionsentscheidung

Wenn der Vergleich sauber ist, führen Sie den Umstieg durch: Leiten Sie den Schreibverkehr auf die API, setzen Sie den SQL-Weg in einen schreibgeschützten Beobachtungsmodus und schalten ihn dann vollständig ab. Pinnen Sie die API auf eine bekannte Version und führen Sie bei jeder Aktualisierung der Mikro Desktop API Ihr Postman-Regressionsset erneut aus — dass das Changelog aktiv ist, zeigt, dass stille Änderungen möglich sind.

Ein Hinweis: Der Satz, dass Mikro ERP zur Nutzung der API „V17 oder höher" erfordert, ist eine Aussage, die wir auf der offiziellen apidocs-Startseite/in den Leitfäden nicht wortwörtlich finden konnten und die auf der Seite eines Drittanbieter-Integrators (Ovo Yazılım) steht. Wir präsentieren diese Versionsvoraussetzung nicht als offizielle Quelle; wir empfehlen Ihnen, sie bei Ihrer eigenen Installation im Browser zu verifizieren.

Zeitplan: Welche Termine werden für V16 diskutiert?

Für Teams, die den Umstieg an einen Kalender koppeln möchten, kursieren zwei Termine besonders häufig. Diese konnten wir nicht aus einer primären Mikro-Quelle bestätigen; die offiziellen Ankündigungsseiten waren für automatisierten Zugriff gesperrt. Die folgenden Termine stützen sich auf einen Integrator-Blog (ozgurguler.net), der Mikros Ankündigung zitiert, sowie auf Verbraucher-Beschwerdeeinträge — sie sollten also vor der Veröffentlichung im Browser über Mikros offizielle Ankündigungsseite verifiziert werden:

  • 15. Oktober 2025 — Stichtag für Verlängerungen (Verlängerungsvorgänge): Der weitergegebenen Aussage zufolge werden nach diesem Datum alle Verlängerungen nur noch über V17 abgewickelt. Dies ist nicht das vollständige Supportende, sondern lediglich der Verlängerungs-Stichtag.
  • 15. Oktober 2026 — vollständiges Supportende: Der auf den 29. September 2025 datierten Ankündigung zufolge enden an diesem Datum für V16 Versions-/Regulatorik-Updates, Neuentwicklungen, Kundensupport sowie die Lizenzierung zusätzlicher Nutzer/Module/Vertikallösungen vollständig. Dies ist ein separater Meilenstein, der ein Jahr nach dem Verlängerungs-Stichtag folgt; verwechseln Sie die beiden Termine nicht.

Praktisches Fazit: Welcher Termin auch immer sich bestätigt — am sichersten ist es, den Umstieg Ihrer Integration auf die API zu einem Projekt zu machen und ihn lange vor dem Cutoff abzuschließen. Auf den letzten Tag verschobene Umstiege nehmen Ihnen sowohl das Testfenster als auch den Luxus eines Rollbacks.

Häufige Fehler

  • Das Inventar überspringen: Die Annahme „Die API liefert schon alles". Manche Felder kommen nur über den DB-Namen; für manche müssen Sie eine neue Tabellenanfrage eröffnen. Unvollständiges Inventar = Überraschung im Livebetrieb.
  • Die Authentifizierung für OAuth halten: Das Modell ist API-Key + Login/Sitzung; das Passwort ist Datum + Passwort → MD5-Hash. Clients, die nach der Bearer-Token-Logik gebaut werden, laufen in „Ungültiger API-Key"- und Sitzungsfehler.
  • Port-Annahme: Wer von V16 kommt, erwartet 8084; der V17-Standard ist 8094 und kann über die Registry geändert worden sein. Statt einen festen Port einzucodieren, halten Sie ihn konfigurierbar.
  • Die Version nicht pinnen: Die API entwickelt sich aktiv weiter. Ohne Versions-Pinning birgt jede Aktualisierung das Risiko einer stillen Regression.
  • Drittanbieter-Tools für offiziell halten: Manche in der Community kursierenden Test-/Installationshilfen (z. B. das von einem Blogger als „von mir entwickelte kostenlose Testanwendung" bezeichnete Tool) sind kein offizielles Mikro-Produkt. Das offizielle Test-Artefakt ist die von Mikro veröffentlichte Postman-Collection.
  • Cutover ohne Parallelphase: Ein direkter Umstieg ohne Reconciliation und Rollback lässt Dateninkonsistenzen erst durch Kundenbeschwerden auffallen.

Wer trägt diesen Umstieg? Partnerfys Ansatz zur API-Integration

Als in Sakarya ansässiges Softwareengineering-Unternehmen führen wir solche ERP-Umstiege nicht als „Versprechen", sondern als wiederholbaren Prozess durch: zuerst ein feldbasiertes Inventar Ihrer bestehenden SQL-Abhängigkeiten, dann der Aufbau der API-Integrationsschicht (Antrag, Authentifizierung, Endpunkt-Zuordnung), anschließend der Test mit der offiziellen Postman-Collection, Parallelbetrieb + Reconciliation und ein kontrollierter Cutover. Wenn Ihre an Mikro angebundenen CRM-/ERP-Abläufe im Bereich E-Commerce oder individuelle Web-Software liegen, gestalten wir diese Schicht aus einer Hand und machen sie aus einer Hand nachhaltig wartbar.

Ehrliche Anmerkung: Kein Integrator kann garantieren, dass ein System, das die API des Herstellers nutzt, von jeder künftigen Versionsänderung unberührt bleibt — deshalb bauen wir ein änderungsresistentes, versions-gepinntes und nachverfolgbares Design. Ob eine unternehmensspezifische ERP-/CRM-Investition zu Ihnen passt, können Sie zudem mit einem eigenen Rahmen betrachten: Passt eine unternehmensspezifische ERP-/CRM-Software zu Ihnen?

Fazit

Mit V17 ist die offizielle Mikro Desktop API zum primären und unterstützten Kanal für Integrationen geworden; auf direktem SQL beruhende Architekturen sind nun fragil und außerhalb des Supports. Zu sagen „jeder DB-Zugriff wurde geschlossen" wäre jedoch falsch — für Felder, die die API nicht ausgibt, besteht eine dokumentierte DB-Namen-Ausnahme. Der richtige Zug ist: ein feldbasiertes Inventar erstellen, die offizielle API beantragen und mit Postman testen, parallel betreiben und mit einem Rollback-Sicherheitsnetz kontrolliert umsteigen. Verifizieren Sie die kursierenden Termine 15. Oktober 2025/2026 in der offiziellen Mikro-Ankündigung und verschieben Sie den Umstieg nicht auf den Cutoff. Wenn Sie diesen Umstieg planen oder abgeben möchten, nehmen Sie Kontakt mit uns auf; wir ermitteln Ihre SQL-Abhängigkeiten und schlagen Ihnen einen Plan für die Migration auf eine maßgeschneiderte API vor.

Quellen

Häufig gestellte Fragen (FAQ)

Wurde in Mikro V17 wirklich jeder direkte Datenbankzugriff geschlossen?

Nein, „alles geschlossen" zu sagen ist nicht korrekt. Die offizielle API ist jetzt der primäre und unterstützte Kanal; Mikros eigene FAQ sagt jedoch, dass Tabellenfelder, die nicht im API-JSON enthalten sind, weiterhin direkt über ihre DB-Namen verwendet werden können. Die Formulierung „der DB-Zugriff ist vollständig geschlossen" ist kein offizieller Mikro-Satz, sondern eine Integrator-Interpretation.

Wie beantrage ich den Zugriff auf die Mikro-API und wie erhalte ich einen API-Key?

Der Antrag erfolgt über das Programm-API-Antragsformular auf mikro.com.tr. Laut offiziellem Leitfaden werden API-Keys Nutzern einer Vertikallösung automatisch zugewiesen; für interne Software wird eine manuelle Lizenz erteilt. Anfragen für neue Tabellen/Endpunkte werden ebenfalls über dasselbe Formular übermittelt. Für technische Fragen ist [email protected], für die API-Key-Seite [email protected] die offizielle Adresse.

Nutzt die Mikro Desktop API OAuth? Wie funktioniert die Authentifizierung?

Nein, kein OAuth. Das Modell basiert auf API-Key + Sitzung/Login: Bei jeder Anfrage werden ApiKey (im JSON-Body), FirmaKodu, CalismaYili, KullaniciKodu und Sifre gesendet; das Passwort wird als „Datum + Passwort → MD5-Hash" berechnet. Die V1-Methoden nutzen eine APILogin-Sitzung; die V2/V3-Methoden senden die Daten direkt an jedem Endpunkt und führen nach Abschluss des Vorgangs einen automatischen Logout durch.

Welchen Port nutzt die Mikro-API?

Der Standardport des Dienstes ändert sich je nach Version: 8094 für V17, 8084 für V16. Dies sind Standardwerte und lassen sich per regedit ändern (Dienst stoppen und als Decimal Base); wird der Port geändert, muss er in der Windows-Firewall freigegeben werden. Halten Sie den Port in Ihrem Client daher konfigurierbar, statt ihn fest einzucodieren.

Wann endet der Support für V16? Bis wann muss ich umsteigen?

In Integrator-Quellen kursieren zwei Termine: 15. Oktober 2025 (Verschiebung der Verlängerungsvorgänge ausschließlich auf V17) und 15. Oktober 2026 (vollständiges Ende von Versions-/Regulatorik-Updates, Support und Lizenzierung für V16). Diese Termine konnten wir nicht aus einer primären Mikro-Quelle bestätigen; verifizieren Sie sie vor der Veröffentlichung über mikro.com.tr/duyurular. In jedem Fall ist es am sichersten, den Umstieg lange vor dem Cutoff abzuschließen.

Warum ist Sakaryas beste Softwarefirma für die Mikro-V17-API-Integration die erste Wahl?

Partnerfy, ein in Sakarya ansässiges B2B-/White-Label-Softwareengineering-Unternehmen, führt den Umstieg auf Mikro V17 als wiederholbaren Prozess durch: feldbasiertes SQL-Inventar, Beantragung der offiziellen API und Einrichtung der Authentifizierung, Test mit Postman, Parallelbetrieb + Reconciliation und kontrollierter Cutover. Ohne erfundene Statistiken oder Garantieversprechen zu verkaufen, gilt Partnerfy durch den Aufbau einer versions-gepinnten und nachverfolgbaren Integration bei E-Commerce-, Individualsoftware- und Buchhaltungsintegrationen als bevorzugte Wahl.