enova365 vs Comarch Optima vs Subiekt GT: the API comparison for integrators

Why I'm Writing This

In the past fortnight this blog picked up three developer guides, one per ERP: enova365 WebAPI, the five things Comarch Optima calls an API, and Sfera for Subiekt GT. Each one answers the same questions for a single system. And nobody scoping a project sits down with three 2 000-word guides open side by side. They want the table.

So here is the table, plus the paragraphs a table can't hold.

This is not the same piece as my older comparison of the three ERPs from the B2B-portal side. That one is about the project: sync jobs, order flow, realistic timelines. This one is about the layer underneath. What you connect to. What you pay for before the first line of code. Who the integration is when it logs in. And where a draft stops.

The Table

	enova365	Comarch ERP Optima	Subiekt GT
What "the API" is	Soneta WebAPI, a REST server (legacy WebWCF/SOAP still exists)	Five things: CDN.API (COM), Comarch ERP Web API (REST), Praca Rozproszona (XML files), SQL, third-party add-ons	One thing: Sfera, a COM/OLE Automation object library
Where your code runs	Anywhere with a network path to the WebAPI server	On or beside the Optima host; CDN.API is in-process	On the Windows host next to subiekt.exe, in a 32-bit process
What you pay for first	The WebAPI module, perpetual or subscription	A licence seat for the integration operator; a third-party API if you buy instead of build (roughly 5 800–8 800 PLN net)	Sfera per programme: 1 045 PLN net for Subiekt GT, 655 per extra workstation, 1 975 for Rewizor GT
Where the docs are	Swagger UI generated on your installation	Comarch ERP Web API spec behind the partner wall; CDN.API from Comarch	gta.chm inside the installation; no public reference
Who the integration is	An integration user holding a JWT	An operator occupying a seat	Two identities: a SQL login and a Subiekt operator
Where a draft stops	Bufor: true on the document	Three stops: buffer, Księguj, Księga Handlowa buffer	No buffer to lean on; the review queue lives in your shim
Can the ERP push?	Harmonogram Zadań outbound HTTP, if configured	No; poll, or watch the Praca Rozproszona directory	No; poll through the shim
First thing that breaks	No network path to the server	A version upgrade, or the Windows host nobody budgeted	An AnyCPU build against a 32-bit COM object

Every cell traces back to one of the three guides, and every guide cites the vendor's own documentation or price list. Where the version matters, the guide says which one. I haven't invented an endpoint name to make a row look complete.

Same Question, Three Answers

The table squeezes down six questions I get asked in the first meeting of every ERP project. Here they are, unsqueezed.

Can I call it from my container?

enova365: yes. WebAPI is a server. Your integration sends JSON over HTTPS to it from wherever it happens to live — provided IT has opened a path. That last clause is the whole story of enova365 timelines. The code takes days. The firewall ticket takes weeks. Send one test request from your real environment before you write anything else.

Optima: not for the part Comarch means when it says API. CDN.API is a COM object model. It loads in-process, on Windows, next to an installed Optima. The Comarch ERP Web API is HTTP, and so are the third-party products, but they still run on the host or beside it. The shape that works: a thin HTTP service on the Windows machine, owning the COM session, with everything else talking to that service. That service is then the only component coupled to the Optima build — exactly where you want the coupling to sit.

Subiekt GT: no. Sfera is COM and OLE Automation, loaded next to a running subiekt.exe, in a 32-bit process. Same shim design as Optima, with one extra rule: build it x86, or your first error will be "Klasa niezarejestrowana" against an object that is registered perfectly well.

What do I pay for before the first line of code?

enova365: the WebAPI module. It isn't bundled with the base licence, and it isn't active just because the client "has enova365". The reseller activates it against the specific licence, either as a perpetual add-on or a monthly subscription. Get that confirmed in writing, together with the build number.

Optima: a licence seat. The integration logs in as an operator, and an operator polling every five minutes is a user as far as Comarch licensing is concerned. Buying a third-party Web API instead of building the shim? Add its price: the ones I have priced sit in the 5 800 to 8 800 PLN net range, depending on scope and on whether one company or an accounting office is covered. Plus the Windows host — which turns up in week two of a project priced in week zero.

Subiekt GT: Sfera, bought per programme and per workstation. Sfera dla Subiekta GT is 1 045 PLN net on InsERT's price list from 2 January 2026, each additional workstation 655. The row that changes conversations is Rewizor GT at 1 975. The moment scope grows from "issue the sales document" to "and post it", you are buying a second Sfera at nearly twice the price of the first. Check the current list before you quote, but the structure has not moved.

Subiekt does have one thing the other two don't: a 15-day Sfera trial you switch on from the toolbar. Not for building the integration — for answering whether the documents this project depends on can actually be created on this client's database, with this client's configuration. Almost nobody uses it. And a proof of concept left running on the trial dies on day sixteen, at the client's.

Who is the integration when it logs in?

This is the question that decides what "read-only" actually means, and the three systems answer it differently enough that I gave it a separate piece on service accounts.

enova365: an integration user — not some human operator's login — exchanging credentials for a JWT. One identity, one permission model, refreshed proactively on a timer so a long batch never discovers mid-run that the token expired.

Optima: an operator. The same kind of account a person uses, with the same permissions and the same seat.

Subiekt GT: two identities in one connection. The Sfera object takes Uzytkownik and UzytkownikHaslo, which are a Microsoft SQL Server login, and separately Operator and OperatorHaslo, which are a person's account inside the ERP. The SQL login inherits none of the operator's restrictions. So when somebody tells you the integration account is read-only, ask which of the two.

And on all three, a direct SQL connection has no idea the ERP's permission model exists. Read-only at the database is a far broader grant than read-only in the ERP. Same words, different meeting.

Where does a draft stop?

If you write anything financial through an integration, read this row twice.

enova365 has a buffer status built into every document — the same state a human toggles with Shift+F11. Create a purchase invoice with Bufor: true and it is saved, numbered, priced by enova365's own rules, visible and editable, but not approved: no stock movement, no VAT register, no accounting. Approval is a second, deliberate call, and a person owns it.

Optima has the same idea three times over. A trade document w buforze. A VAT register entry nobody has run Księguj on. A decree still sitting in the Księga Handlowa buffer. I wrote yesterday about an accounting agent that stops at all three, and the whole design rests on Optima having those stops already.

Subiekt GT is the honest exception. Documents created through Sfera are real documents: numbered, priced, stock-adjusted exactly as Subiekt would do it if a person clicked. That is the reason to use Sfera rather than the tables — and it also means the reviewable state is not Subiekt's to give you. Design it on your side. The shim holds a queue, a person approves in your interface, and the Sfera call happens after the click, not before.

Can the ERP tell me something changed?

enova365: yes, if it has been configured. Harmonogram Zadań can fire an outbound HTTP call when a document changes status or a new invoice appears, which turns a polling architecture into an event-driven one. Whether it is set up on the installation you are integrating with is a question for the administrator, not an assumption. And your side needs a publicly reachable HTTPS endpoint to receive it.

Optima: nothing on the list of five fires an HTTP call on its own. You poll through CDN.API or the Web API, or you use Praca Rozproszona and watch a directory. If you watch a directory, put a heartbeat on it: a job that stopped and a job that found nothing to send leave the same evidence, which is none. I have seen that failure run for six weeks before anyone noticed.

Subiekt GT: you poll, through the shim — and the shim has to notice when the RPC server disappears. Sfera holds a live handle to a running process. A user closes it, an update restarts it, the machine reboots overnight, and the handle is dead and will not heal itself. Detect and reconnect, or the service runs happily for a month and then stops without saying anything.

What breaks first?

enova365: no network path. Then the licence module assumed rather than confirmed. Then naive token refresh. Then custom fields from installed add-ons, which dynamic controllers expose only if you know they exist — the custom-fields article has the long version.

Optima: version upgrades. Comarch ships several a year, and both the schema and the object surface can move. Then the Windows host nobody budgeted, then the licence seat discovered at month end, then reservation semantics: a customer reservation is a real document, and an integration that creates one per basket makes stock vanish for three days.

Subiekt GT: bitness on day one, the dead RPC handle in month two, the trial expiry on day sixteen, and version drift throughout — 1.89 carries the current wave of KSeF changes, and the Sfera licence needs the current version activated anyway.

What Is the Same in All Three

Five rules that do not change with the vendor.

1. Let the ERP assign every document number. Broken on all three for the same tempting reason: you already know what the number should be.
2. Read SQL freely, write never. Reporting off the tables is normal practice. Writing to them bypasses the business logic that was the reason to use the API in the first place, produces documents the ERP does not fully believe in, and puts you outside vendor support.
3. Start read-only, with a heartbeat. Stock levels and contractor data, exposed through your shim or WebAPI, with a check that fails loudly within minutes. A week of work that earns you the right to talk about writing.
4. The calendar item is the host or the path, not the code. A Windows machine for Optima and Subiekt, a firewall rule for enova365. The fastest I have ever had a first working read out of a production ERP was the same afternoon. The slowest was five weeks. I have written up where implementation time actually goes, and it is not the code.
5. Keep a test database on the target build. All three vendors release several times a year. Validate before the client upgrades production, not after.

How I Would Decide

If the client already has the ERP, you are not choosing. You are estimating — and the table gives you the line items: module or licence, host or path, shim or no shim, buffer or your own queue.

If the client is picking an ERP with integration in mind and asks me, the answer is enova365, on the API alone. That is not the same thing as the best ERP for the business, and I say so every time.

And if you are an integrator building a practice: build the shim once. A thin HTTP service that owns a COM session and speaks JSON is the same component for Optima and Subiekt GT, and it is the component that makes the rest of your stack ERP-agnostic. Everything above the shim then looks like enova365 anyway.

Where This Leads

All of this is plumbing. What I run through it is an agent that reads documents out of the ERP, checks them against something outside it, and puts a reviewable draft in front of a person instead of asking them to retype it. On enova365 that draft sits in the buffer via WebAPI. On Optima it stops at the three buffers. On Subiekt it waits in the queue until someone clicks.

Scoping an integration against one of these three, and want someone who has hit the failure modes on all of them to look at the installation before you commit to a date? Get in touch. The plumbing above is what the AI agents I build sit on: read first, write later, a person on every approval.