Integrating Comarch Optima with a B2B Portal — How It Actually Works
Comarch Optima Is the Most Common Polish ERP — and the Hardest to Integrate Cleanly
Comarch Optima has the largest install base of any ERP in the Polish SMB market. If you sell software or build portals here, you meet it more often than enova365, Subiekt, or anything else. Which means the question "how do we connect our B2B portal to Optima?" comes up constantly — and the honest answer is not the one people want to hear.
Optima does not have a clean, documented REST API that covers a wholesale portal's needs end to end. enova365 does, via Soneta WebAPI, and it makes that integration a 3–5 day job. Optima is a 7–10 day job for the same feature set, and the extra time is not padding. It is the sync layer you have to build yourself because the ERP does not hand it to you.
This article is for businesses running Comarch Optima who want to connect a B2B wholesale portal, and for the people who will build it. If you are still choosing an ERP, the comparison of B2B portal integrations across Subiekt GT, Optima, and enova365 has the full picture. For what a portal does beyond the ERP layer, the wholesale B2B portal overview covers the rest.
The Three Real Integration Routes
There is no single "Optima API" that does everything. In practice you combine one or more of three approaches. Each has a clear use, and a clear failure mode.
1. Praca Rozproszona (Distributed Work) — XML Exchange
Praca Rozproszona is Optima's built-in mechanism for exchanging documents between databases as XML files. It was designed for branch offices syncing to head office, but it is the officially sanctioned path for getting documents into Optima from outside.
What it does well: order write-back. The portal generates an XML document describing a sales order (RO — rezerwacja odbiorcy, or a faktura/paragon depending on the flow), drops it into the exchange location, and Optima imports it — applying its own numbering, its own pricing rules, and its own validation. This is the correct way to create documents in Optima. You never invent document numbers on the portal side.
What it does poorly: real-time reads. XML exchange is batch-oriented. It is fine for orders flowing one direction on a schedule, awkward for live stock and price lookups where the portal needs an answer in the same second.
2. Direct SQL Read Against the Optima Database
Optima stores everything in a Microsoft SQL Server database. Reading from it directly is the fastest way to get catalogue, pricing, and stock data out.
Use it read-only. Pulling the product catalogue, price lists, stock levels, and contractor data with SELECT queries is common, performant, and reliable. Many production Optima–portal integrations do exactly this for the read path.
Never write to it directly. The schema is undocumented for external use, it changes between Optima versions, and writing straight into the tables bypasses every piece of business logic Optima runs on save. You will corrupt data, and you will void Comarch support the moment they see foreign writes. Orders go back through Praca Rozproszona or the CDN API — never a raw INSERT.
3. CDN API and Middleware
Optima exposes an automation model — historically the CDN API, a COM/OCX object layer that runs on Windows alongside the Optima installation. It lets external code drive Optima the way a user would: create documents, read data, trigger operations, all through Optima's own logic. It is more robust than raw SQL for writes, but it is Windows-bound and not built for cloud-native, high-concurrency web traffic.
For that reason, most serious Optima integrations put a middleware service between the portal and the ERP. A small Windows-hosted connector sits next to Optima, talks to it via CDN API and controlled SQL reads, and exposes a clean internal API to the cloud-hosted portal. This is the pattern I reach for: it isolates all the Optima-specific coupling in one place, so a version upgrade touches one adapter instead of the whole portal.
A Reference Architecture That Holds
Here is the shape of an Optima–portal integration that survives contact with production and with the next Optima update.
The portal runs in the cloud, as it should. It never talks to Optima directly and never holds Optima credentials.
A middleware connector runs on-premise or on a Windows VM with network access to the Optima SQL Server. It does three jobs:
- Read sync (SQL, read-only): on a schedule, it pulls catalogue, price lists per contractor, and stock levels from the Optima database and pushes them to the portal's own database. Catalogue every 30–60 minutes, prices every 15 minutes, stock every 5–15 minutes depending on turnover.
- Order write-back (Praca Rozproszona / CDN API): when a client confirms an order, the portal calls the connector, which creates the document in Optima through the sanctioned path. Optima assigns the number and returns it. Store that number — it is what the client and your accounting both reference.
- Status and invoice sync (SQL read): the connector reads order status changes and generated invoices back out, so the portal can show fulfilment progress and let clients download their faktury.
The coupling lives in one module. Every table name, every CDN object version, every XML schema quirk is inside the connector. When Comarch ships a new Optima build, you validate and, if needed, fix one component — not fifty portal endpoints.
Pricing: The Same Rule as Every Polish ERP
Polish wholesale pricing in Optima is layered — cennik bazowy, grupy cenowe (price groups per contractor), rabaty indywidualne, progi ilościowe, promocje czasowe. These interact by precedence rules inside Optima's pricing engine.
Do not rebuild that logic in the portal. Read the final, calculated price for the specific contractor and product from Optima, display that, and re-validate at order confirmation. If you reconstruct the discount math yourself, you will eventually hit a case where the portal shows one price and the invoice says another — and that is a client-trust problem that is hard to walk back. The ERP integration comparison goes deeper on why the ERP must stay the single source of pricing truth across all three systems.
The Version-Lock Trap
The single biggest difference between an Optima integration that lasts and one that breaks every quarter is how you handle upgrades.
Comarch releases new Optima builds several times a year. Both the SQL schema and the CDN API surface can shift between them. An integration wired directly to specific table structures — with no isolation layer — is a maintenance liability that breaks on the next update, usually at the worst time.
Three practices keep it stable:
- Isolate all Optima coupling in the connector. One module knows the table names and object versions. Nothing else does.
- Keep a test database on the target Optima version. Before any production upgrade, run the full integration against a copy of the client's database on the new build.
- Validate on every Optima update. Treat each ERP upgrade as a release event for the integration, with its own test pass. This is not optional for Optima the way it almost is for enova365.
Timeline and Cost
Development time: 7–10 days for a standard full bidirectional integration — read sync for catalogue, prices, and stock; order write-back via Praca Rozproszona or CDN API; status and invoice retrieval. Compare that with 3–5 days for enova365 and 5–7 for Subiekt GT via Sfera.
Calendar time: 3–4 weeks. The gap is the usual story plus one Optima-specific item: you need a test copy of the client's database and network access to the SQL Server before real work starts. Getting a database backup and a Windows host for the connector approved routinely adds a week.
Ongoing cost: budget for revalidation on Optima upgrades. It is small if the coupling is isolated, painful if it is not. This is the recurring cost that enova365 mostly avoids — worth knowing before you commit to Optima as the integration target.
If cost predictability matters more than anything, read how much a B2B portal actually costs — the ERP integration line item is where Optima and enova365 diverge most.
Optima vs enova365: The Honest Take
Optima is not a bad ERP. It has the biggest install base in Poland for good reasons — broad functionality, strong accounting, a huge partner network. But as an integration target for a B2B portal, it asks more of you than enova365 does. No clean REST API, more upgrade fragility, more custom sync code.
If you already run Optima, none of that is a reason to switch — the integration is entirely doable, thousands of them exist, and the middleware-connector pattern makes it robust. Go in knowing it is a 7–10 day build with an ongoing revalidation commitment, not a weekend plug-in. If you are still choosing between ERPs and integration effort is a real factor in the decision, that is exactly what the Subiekt vs Optima vs enova365 comparison is for.
Connecting Comarch Optima to a B2B Portal?
Optima integrations are very doable — the key is architecture that isolates the ERP coupling and a plan for surviving version upgrades. Get those two right and it runs for years.
If you are running Comarch Optima and looking at a B2B portal, or you have a portal that needs to plug into Optima, get in touch. I will look at your specific setup — Optima version, database access, order flow — and tell you exactly what the integration will require on your side.
For the full ERP-by-ERP picture, see the Subiekt GT, Optima, and enova365 integration comparison and the B2B ERP integration service page.
Let’s talk about your project
Free 30-minute consultation. We’ll figure out if and how I can help.
