Comarch Optima API limits: the ceilings you find out about late

The Limit That Isn't There

The Optima API has no rate limit. Comarch publishes no number you can design against, and that is a problem rather than the licence it sounds like.

People hear "no limit" as permission. It's the opposite.

A rate limit is a contract. It tells you the safe speed, and when you break it you get a 429 — unambiguous, in your logs, at the moment you caused it. Optima hands you no such contract. Nothing in the system will tell you that your five-minute polling loop is now the heaviest single consumer of a database that eleven people are trying to issue invoices in. The signal arrives days later, in a different medium, addressed to somebody else: the ERP has been slow since your integration went live.

The limits are real. They're just not where an API-shaped instinct goes looking. There are four, and only one is technical in the way developers expect. This is the failure-modes companion to the Optima API guide, which sorts out which of the five things called "the API" you're actually using. Read that one first if CDN.API doesn't mean anything specific to you yet.

Ceiling One: The Seat, and the Key That Phones Home

CDN.API logs in as an operator, so your integration is a user in the licensing sense. It occupies a module seat while it works, and it competes for that seat with the people the system was bought for.

The consequence is seasonal, which is why it survives testing. In February your job and your users coexist without friction. On the 20th of a month, with everyone closing, the automation either can't get a licence or takes one somebody needs. Integrators who do this for a living put the integration's licences on a separate key, allocated to it exclusively, and this collision is exactly why.

Behind the seat sits a second timer almost nobody accounts for. A virtual key has to reach Comarch's servers at least every 24 hours for Optima modules — 72 hours for XL and Altum. If Key Manager loses its connection past that window, modules stop being served and workstations can't log in. Key Manager polls roughly every two hours, so recovery isn't instant either.

That's an availability dependency, so treat it as one. Your integration's uptime now includes a client's outbound internet connection and Comarch's licensing infrastructure. A firewall rule changed on a Friday afternoon is enough to take it down. And when it happens, everything in your logs says authentication failure — so every hour you spend in your own code is wasted.

Ceiling Two: The Database Engine Nobody Chose

The database engine is the ceiling I check first on an unfamiliar installation. It's the cheapest one to check and the most expensive one to hit.

Comarch documents it on its own help pages: MS SQL Server Express editions from 2016 through 2022 cap a single database at 10 GB — older 2008 Express was 4 GB. Express also limits how much RAM the engine may use, which is why the tuning bulletin tells you to set Max Server Memory to about 1400 MB on Express against 13500 MB on a 16 GB full edition.

Now the part that turns a footnote into a project risk. A great many Optima installations run on Express because Express arrived with the installer. That was not a capacity decision. It was a default, taken years ago by whoever ran setup, and nobody has revisited it since — nothing in the software mentions it again until the day writes start failing.

Your integration is a rowcount machine pointed at that database.

So compute the ceiling date before you quote. Three numbers: the database size today, its size twelve months ago (an old backup file's size is close enough), and the month the line crosses 10 GB. Fifteen minutes of work. On a growing wholesaler I routinely see 5 to 14 months of headroom — which is to say, less than the lifetime of the thing you're about to build.

If that date lands inside your project's horizon, a SQL Server licence belongs in your proposal as a line item the client decides on with open eyes. Leave it out and it becomes an emergency next spring — and by then it's your integration that "filled up the database".

Ceiling Three: One Windows Host, One Session Model

CDN.API is a COM object model: it runs on Windows, in-process, beside an installed Optima. And it works in sessions — log in, do the work, log out. Everything about throughput follows from those two facts.

You can't scale it horizontally by starting more containers somewhere cheap. Capacity is that one Windows host, and the ceiling is whatever its CPU and RAM will carry alongside an ERP. Integrators who support Optima commercially state the requirement plainly: the server must run continuously, and switching it off at night causes delays and synchronisation problems. Ordinary sentence, real cost attached — the host is infrastructure with an availability target, not a workstation in the corner.

The session model then punishes both of the obvious implementations. Log in per record and you pay session setup thousands of times, so it crawls. Hold one session open for a six-hour batch and an ERP upgrade, a network blip or a restart kills the whole run — which you find out in the morning. What survives is batches with checkpoints and resumable work. Build that on day one, not after the first bad night.

Ceiling Four: The Holes in the API Itself

CDN.API doesn't cover everything, and the gaps get filled with SQL. That comes from published integration documentation, not from me.

Operations that can't be performed stably or efficiently through CDN.API are done with direct SQL queries instead — specifically attribute handling and the shipment waybill number, with [CDN].[DefAtrybuty], [CDN].[DokAtrybuty] and one field on [CDN].[TraNag] named as needing direct access. Attributes are excluded from the API path for performance reasons.

Two things follow. First, "use the API, never SQL" is a rule with documented exceptions in production systems built by people who do this full time. Pretend otherwise and you'll estimate against a coverage the API doesn't have. Check early whether the fields you need are reachable through CDN.API at usable speed — a field that's technically writable but slow is the same problem as a missing one.

Second, the exception is narrow and it should stay narrow. Reads for reporting: fine. A tiny, named, written-down set of writes because there is no other route: sometimes unavoidable. Everything else goes through the API, so document numbering and stock logic stay Optima's job. And notice what direct SQL quietly throws away — the permission model. A SQL connection doesn't know operator rights exist. Same trap I described for enova365 service accounts: read-only at the database is a far wider grant than read-only in the ERP, and both get called read-only in the same meeting.

While you're in there, check the access the integration actually needs. Published requirements ask for the SQL roles CDN and CDNRaport on both the company database and the configuration database. Two databases — which surprises people who only planned for one.

The Numbers That Warn You Before Users Do

Optima won't tell you that you're pushing too hard, so take the numbers from the layer that will. Comarch's own tuning bulletin OPT057 gives the thresholds, and these are the ones worth a dashboard:

• Page Life Expectancy above 300 seconds. The single best early warning here. When a heavy job churns the buffer cache, this falls first — before anyone notices the UI.
• Buffer Cache Hit Ratio above 90% and Available Bytes above 300 MB — memory pressure.
• Processor Queue Length under 2 per core, CPU under 80%, Disk Time under 55%.

Two more settings matter specifically when your job runs against a live database. Blocking caused by query parallelisation is tuned with Max Degree of Parallelism and Cost Threshold for Parallelism — if parallelism-driven blocking is a meaningful share of what you're seeing, lower MaxDoP or raise the cost threshold. And sys.dm_db_missing_index_group_stats, sorted by avg_user_impact, will usually show that your own reporting queries are the ones begging for indexes nobody ever created.

Take a baseline before go-live. Without one you can't answer the only question anybody will ask — did the integration make Optima slower — and with no answer, the newest component is always guilty.

Setting a Budget Nobody Set for You

Decide the speed yourself, in writing, because the platform won't do it for you. That's the whole design rule.

Give the job a window and make it respect the working day — the full sync stops when people start, whatever it has left. Give it a batch size you took from a measurement rather than from optimism, with checkpoints so a stopped run resumes instead of restarting. Split reporting off the transactional path: analytical queries are what turn a busy morning into a slow one, and read-only reporting is exactly the case where a replica is legitimate. Make every write idempotent, because a resumable job will eventually repeat one.

None of this is Optima-specific craft. It's ordinary engineering discipline, and it's required here precisely because the platform gives you none of the guard rails a modern API would.

The One-Hour Ceiling Inventory

Before quoting any Optima integration, ask four questions. It takes about an hour and it moves estimates more reliably than anything else I do at that stage:

1. Which SQL edition, and how big is the database? Express or full, size now, size a year ago, ceiling date.
2. Which key, how many module seats, and is the integration on its own key? Plus: does the site have reliable outbound internet for the 24-hour check-in?
3. Which Optima build, and what's the upgrade cadence? Comarch ships several releases a year, and commercial integrations commonly support only the last three versions. If the client is two behind and upgrading in March, that's your calendar, not theirs.
4. What does the existing integration already do with direct SQL? If something is writing to Optima's tables today, you inherit it whether you wrote it or not.

Do this before the estimate, not in week three. Same pattern as the access lag — the questions that move a date are cheap, boring, and asked too late.

Where This Leads

None of the four ceilings is a reason not to build. They're a reason to know which one you'll hit first, and to say so before anyone commits to a date. Two of them — the licence key and the SQL edition — aren't even technical decisions. They're commercial ones, made years ago by somebody who wasn't thinking about integration, and both are fixable with a purchase order if you raise them early enough.

The work worth doing on top of this plumbing is the same as ever: something that reads documents out of Optima, checks them against a source outside the ERP, and puts a reviewable draft in front of a person instead of asking them to retype it. That's what the Optima accounting agent does, and every ceiling above constrains how fast it may read — not whether it works at all.

Scoping an Optima integration and want the ceilings measured before you commit to a date? Get in touch. The four questions above take an hour, and I've never run them without at least one answer changing the plan.