Mikro V17 Closed Direct Database Access: Migrating Your Integration to the API (2026)

Short answer: under Mikro's V17 architecture, you now have to build your integration on top of the official Mikro Desktop API rather than on direct SQL access. The line you'll hear from integrators in the market — "direct database access was closed in V17, the system became fully API-based" — is a strong summary, but it is not exactly accurate: Mikro's own official documentation clearly states that table fields not exposed in the API JSON can still be referenced directly by their DB names. So the correct reading is this — with V17 the official API became the primary and supported integration channel; a documented "access-by-DB-name" exception still exists for the fields the API does not surface. So what should you do now? Three steps: (1) inventory every one of your current SQL read/write points column by column, (2) map each field to "is there an API endpoint, or do I need the DB-name fallback," and (3) apply for an API Key through the official developer portal, run the new flow in parallel to test it, and then cut over. In this guide we walk through that migration step by step, without invented certainty, grounded in Mikro's official documentation.

As a Sakarya-based B2B / white-label software engineering firm, we manage this migration for Mikro-dependent integrations across e-commerce, custom software and accounting. Below we share both the logic behind the decision and the concrete playbook we apply in the field. We've left every "definite"-looking statement about dates and ports where we could ground it in an official source, and we've clearly flagged the places that are integrator interpretation.

What exactly changed?

Mikro published an official developer portal for its desktop products: apidocs.mikro.com.tr. The portal's tagline is "Develop, Test, Deploy — Mikro API Integration Guide" and it defines its audience explicitly as: Mikro Software Customers, Mikro Software Partners and 3rd-Party Solution Developers. In other words, this API is not just for resellers; it is the official channel for customers' own teams and independent software houses as well.

The API's technical nature is also clear: REST/JSON over HTTP. The official portal provides guides titled "JSON and REST API Fundamentals," "HTTP Protocol and Status Codes" and "Endpoint Usage," along with downloadable official Postman collections for both V17 and V16 ("Current Postman Collection (V17)" and "(V16)"). These collections are the official starting point for your testing phase.

A critical nuance: saying "V17 removed all direct database access" is wrong. According to the official FAQ, "table fields not present in the API JSON can also be used directly by their DB names." The correct framing is this: the official API is now the mandatory and supported primary channel, while the DB-name path is a documented exception for the fields the API does not surface.

Why was direct DB access pushed to the background? (the logic of the decision)

Integrator blogs in the market (e.g. ozgurguler.net, mikrodestek.net) summarize this change as "starting from Mikro V17, direct database access was closed and the system moved to a fully API-based model." This should be conveyed not as an official Mikro sentence but as integrator interpretation, because we could not find this exact wording in Mikro's own sources, and the DB-name exception above softens that absolute claim. Even so, the technical logic of an ERP vendor imposing a controlled API layer instead of direct SQL is clear:

• Stability and schema independence: Direct SQL binds tightly to the table and column structure. When the vendor changes the schema in a release, your queries break silently. An API layer places a contract between the internal schema and the external consumer; even if the internal structure changes, the endpoint contract can be preserved.
• Security and permission surface: Handing your application direct database credentials (a connection string) is the widest possible permission surface. Access through the API delegates authentication to Mikro's own session/authorization mechanism; access can be restricted at the endpoint level.
• Support and predictability: With direct SQL the vendor cannot know what you're reading or writing; because business rules can be bypassed, there is a data-integrity risk. Operations performed through the API are defined, versioned and supportable. Indeed, Mikro publishes a dated V17 API changelog — the oldest record we could see is [17.03a] – 14.04.2025 and the newest is [17.07b] – 05.08.2026. This is proof that the API is actively versioned and evolving.

Who is affected?

Every integration that connects directly to the Mikro database is affected by this migration. The three groups we most often encounter in the field:

• E-commerce integrations: Stores that synchronize stock, price, account and order data between a website/marketplace and Mikro over SQL. Write operations such as stock deduction, invoice/dispatch creation and order transfer are the most critical risks on this side.
• Custom software / in-house projects: Internal developments that use Mikro as the single source of truth — production tracking, field-team apps, B2B dealer portals. For this group, API Key licensing is handled manually (see below).
• Accounting and reporting integrations: Account reconciliation, e-invoice/e-archive bridges, BI/report dashboards and recurring exports. Although most are "read-only," this is the group most deeply embedded in direct table queries.

Whether e-commerce and e-invoice flows on the Mikro side should be solved with a ready-made module or a custom API integration is a decision in its own right; we covered that in a separate article: E-commerce + ERP + e-invoice integration: ready-made or custom API?

The migration playbook: from SQL reads to API endpoints

The steps below are an editorial recommendation we build on top of the facts Mikro documents — items like parallel running and rollback are not a procedure Mikro imposes but standard integration best practice.

1) Field inventory: map every SQL column

The first and most skipped step: extract every table and every column your current integration touches. Then, for each field, choose one of two paths:

• If the field is exposed in the API JSON → read it from the relevant REST endpoint response.
• If the field is not in the API JSON → as the official FAQ states, it can be referenced directly by its DB name. This is an important escape hatch that relieves the pressure of "you must convert everything to the API in one go."
• If it exists neither as an endpoint nor as an accessible field → open a new table/endpoint request via the Program API Application Form (Mikro says, "For new table requests: API Application Form").

Migrations done without this inventory blow up in production with "missing field" errors. Column-by-column mapping is the most tedious but most decisive step of the migration.

2) Authentication and application

Access first: integrators fill out the Program API Application Form. According to the official guide, API Keys are assigned automatically to those using a vertical solution; for in-house software, a manual license is issued. (The "detailed email Q&A evaluation and hand-off to the Password Department" steps described on some integrator blogs are not documented this way in the official material; the official source contains only the form, the licensing distinction, and the contact addresses.)

The authentication model is not OAuth — let us be clear about this. The model is based on API Key + session/login. According to the official guide, the following information is used on every request:

There is a version difference in session management. V1 methods first open a session with APILogin (the address on the official install page: POST http://localhost:8094/Api/APIMethods/APILogin, with FirmaKodu, CalismaYili, ApiKey, KullaniciKodu, Sifre in the body). V2/V3 methods, on the other hand, send the user information directly in each endpoint's JSON and log out automatically once the operation completes. Design this distinction up front when building your architecture (persistent session or on-demand).

3) Installation and port settings

The API is installed via the "Server" option on the version-updates page and registers a Windows service named Mikro Desktop API. The service runs under the NT SERVICE\MikroDesktopAPIContainer account; the port parameters are kept under HKLM\SYSTEM\CurrentControlSet\Services\MikroDesktopAPIContainer\Parameters. If you want to change the port, you stop the service and edit it via regedit (Decimal Base), then open the port in the Windows Firewall.

The default service ports differ by version: 8094 for V17, 8084 for V16. These are defaults and can be changed via the registry; therefore, instead of saying "Mikro changed the port from 8084 to 8094," it is more correct to say "the V16 default is 8084 and the V17 default is 8094." If you have customized this port in your environment, set your call addresses accordingly.

4) Testing: the official Postman collection

Before writing code, verify the calls by hand. Download Mikro's official Postman Collection (V17) package and run the endpoints you flagged in your inventory with your own credentials. Compare the expected responses against your current SQL output; do not go live until you have field-by-field parity. At this stage the official technical support channel is [email protected], and for API Key/partner-side questions it is [email protected].

5) Parallel running and rollback

The step that minimizes risk: run the new API-based flow alongside the old SQL flow. For a defined period, have both paths produce the same data (reads/writes); compare the results automatically (reconciliation). If there is no divergence, confidence grows. During this period, keep your rollback plan ready: with a feature flag you should be able to return to the old flow in one click. This parallel-running/rollback approach is not a Mikro instruction; it is the standard integration safety net we recommend.

6) Cutover and version decision

Once the comparison is clean, perform the cutover: move write traffic to the API, drop the SQL path into read-only observation mode, then shut it off entirely. Pin the API to a known version and re-run your Postman regression set on every Mikro Desktop API update — the fact that the changelog is active shows silent changes are possible.

One caveat: the sentence that Mikro ERP requires "V17 or higher" to use the API is a statement we could not find verbatim on the official apidocs home page/guides; it appears on a third-party integrator (Ovo Yazılım) page. We do not present this version prerequisite as an official source; we recommend verifying it in your own setup via the browser.

Timing: which dates are being discussed for V16?

For teams that want to tie the migration to a calendar, there are two dates in frequent circulation. We could not confirm them from a primary Mikro source; the official announcement pages were closed to automated access. The dates below rely on an integrator blog quoting Mikro's announcement (ozgurguler.net) and on consumer-complaint records — that is, they must be verified in the browser from Mikro's official announcements page before publishing:

• 15 October 2025 — renewal (renewal operations) cutoff date: According to the conveyed statement, after this date all renewals will be done only over V17. This is not the full end of support; it is only the renewal cutoff.
• 15 October 2026 — full end of support: According to the announcement stated to be dated 29 September 2025, on this date version/regulatory updates, new development, customer support and additional user/module/vertical-solution licensing for V16 will end entirely. This is a separate milestone that comes one year after the renewal cutoff; do not confuse the two dates.

Practical takeaway: whichever date is finalized, the safest path is to turn migrating your integration to the API into a project and complete it well before the cutoff. Migrations left to the last day eliminate both the testing window and the luxury of rollback.

Common mistakes

• Skipping the inventory: The assumption that "the API will give everything anyway." Some fields come only by their DB name; for others you must open a new table request. An incomplete inventory = surprises in production.
• Mistaking the authentication for OAuth: The model is API Key + login/session; the password is Date + Password → MD5 Hash. Clients built with a Bearer-token mindset run into "Invalid api key" and session errors.
• Assuming the port: Those coming from V16 expect 8084; the V17 default is 8094 and may have been changed via the registry. Instead of hardcoding a fixed port, keep it configurable.
• Not pinning the version: The API is actively evolving. Without version pinning, every update carries the risk of a silent regression.
• Mistaking third-party tools for official ones: Some test/install helpers circulating in the community (e.g. a tool a blogger calls "the free test app I developed") are not Mikro's official product. The official test artifact is the Postman collection Mikro publishes.
• Cutover without a parallel period: A direct switch without reconciliation and rollback only surfaces data inconsistencies through customer complaints.

Who carries out this migration? Partnerfy's API integration approach

As a Sakarya-based software engineering firm, we run these ERP migrations not as a "promise" but as a repeatable process: first a field-level inventory of your existing SQL dependencies, then building the API integration layer (application, authentication, endpoint mapping), followed by testing with the official Postman collection, parallel running + reconciliation, and a controlled cutover. If your Mikro-connected CRM/ERP flows are on the e-commerce or custom web software side, we design and maintain this layer from a single point of ownership.

An honest note: no integrator can guarantee that a system using the vendor's API will be immune to every future version change — which is why we build a change-resilient, version-pinned and observable design. You can also look at whether a company-specific ERP/CRM investment fits you through a separate lens: Does company-specific ERP/CRM software fit you?

Conclusion

With V17, the official Mikro Desktop API became the primary and supported channel for integrations; architectures embedded in direct SQL are now fragile and unsupported. But saying "all DB access was closed" would be wrong — a documented DB-name exception remains for the fields the API does not surface. The right move is to build a field-level inventory, apply for the official API and test with Postman, and run in parallel before a controlled cutover with a rollback safety net. Verify the circulating 15 October 2025/2026 dates against Mikro's official announcement and don't leave the migration to the cutoff. If you'd like to plan or hand off this migration, get in touch with us; we'll extract your SQL dependencies and propose a plan to move them to a custom API.

Sources

• Mikro Desktop API — Official developer portal (tagline, audience, Postman collections, support addresses)
• Mikro — Installation & port settings (Windows service, NT SERVICE\MikroDesktopAPIContainer, APILogin, V17 default port 8094, regedit)
• Mikro — API Guides / FAQ (auth fields & MD5, DB-name fallback, ports 8094/8084, application form & licensing)
• Mikro — V17 API changelog (releases dated between 14.04.2025 – 05.08.2026)
• Mikro — Program API Application Form (channel for API Key and endpoint/table requests)
• Ovo Yazılım (third-party integrator) — "V17 or higher" prerequisite and port note
• Özgür Güler (integrator) — 15 October 2025 renewal cutoff and the "API-based" interpretation (quoting Mikro's announcement)
• Özgür Güler (integrator) — 15 October 2026 full end of support (quoting the 29 September 2025 announcement)
• Mikro — Official Announcements (primary source to verify the dates in the browser)

Frequently Asked Questions (FAQ)