Sooner or later someone will ask: "can we plug into your system?". A shop your biggest customer runs. A B2B partner who wants to see your stock levels every 15 minutes. A courier asking for a webhook after each shipment. That moment is a decision point — either you expose a custom API over your ERP, or you add one more batch of manual work that someone in the company will patch in Excel for the rest of their career.
This piece is about when it's actually worth exposing an API over Comarch Optima, enova365, Subiekt or Dynamics AX in a Polish SME, how to design it sensibly, and — just as important — how not to turn it into a front door for the entire internet.
When it's worth exposing an API — and when it isn't
Not every problem that looks like "we need an API" is actually solved by one. Before you spend a złoty, be honest about three questions.
- How many times a week is the same piece of information copied by hand or emailed as an Excel? If fewer than five — an API probably won't pay for itself. Automating for its own sake is an expensive hobby.
- Is the data your customer asks for as fresh in the ERP as they need it to be on their side? If stock levels need to be "right now" and you're refreshing them once a day by CSV, the problem won't go away with an API — it'll go away with the customer.
- Will a second, third, fourth integrator show up in the next 12 months with the same ask? One partner is often a one-off Excel-over-email pipe. Three partners with the same ask — that's the signal an API pays for itself without debate.
In practice, three situations make exposing a custom API obvious: B2B partners polling for stock and prices; your own webshop or an Allegro storefront where orders need two-way sync; and mobile apps for field sales that must work when nobody's in the office. In each case, the manual alternative — a CSV at midnight, copy-paste, "I'll get back to you by email" — costs more than the project itself once you look at two or three quarters.
Situations where an API is overkill: a single monthly report for an external accountant (a plain export is enough), a one-off data migration to a new system (an ETL script, not an API), or a "collect leads from a web form" integration (a webhook plus Zapier/Make will do).
35 people, 3 partners, 6 hours a week in sales
At one of our clients — a 35-person industrial parts distributor in central Poland — the problem looked like this: three key B2B customers (manufacturing companies of 200–500 people) contacted their sales team every single day asking "is there still X units in stock", "when's the next batch coming in", "what's our net price for 500 units". Sales reps replied after checking Comarch Optima. The answer went out by email or phone, the customer typed it into their own spreadsheet, and four hours later — when stock had already moved — they'd call again.
Short version: six hours a week of two sales reps lost to asking and answering questions about data a computer could hand over on its own, in a fraction of a second.
We built an API layer over Optima in .NET with four endpoints: stock levels (per SKU, per warehouse), current customer-specific pricing, order history for a given customer, and new-order confirmation. API-key authentication per partner, 60-request-per-minute rate limit, all requests logged. The Optima database itself — never touched directly; the middleware serves from a cache refreshed every 60 seconds, which removes the risk of hammering the production instance.
Result after two months: partners poll the API every 15 minutes on their own, sales reps got those 6 hours a week back and redirected them to new business. The "high-maintenance" customer who used to call several times a day switched 40% of orders from one-off to recurring (because he could finally trust the data). Payback — four months. The project cost less than half a year of one sales rep's salary.
Don't expose the ERP database directly
This is the most common mistake we see at companies that tried to do it themselves. Someone opened the SQL Server to inbound traffic, created an "api_user" account, granted select on everything, and "there you go, you have access". Three weeks later — a production performance issue, because the partner ran a query scanning 400,000 document lines in the middle of the day. Six weeks after that — the api_user credentials leaked in an email forwarded to a subcontractor, and then to their friend.
The rule is short: there must be a middle layer between the ERP and the outside world. In a typical SME a simple .NET service is enough (or Node.js — technology choice is secondary here) that:
- Handles authentication (an API key, OAuth or JWT — not direct database passwords).
- Caches the most frequent requests (stock levels, pricing) for 30–120 seconds. 90% of partner traffic serves from cache, production doesn't even notice.
- Validates incoming requests (page size, allowed filters) so nobody sends
GET /products?limit=99999999. - Logs every request with timestamp, IP, key ID and response time. When something goes wrong — you know exactly when and who.
Middleware isn't a luxury; it's the precondition. Without it, an API isn't an interface — it's a hole in the company.
5 design rules you won't regret a year later
We've seen plenty of APIs designed "quick and dirty" that become a liability three years later because they can't be evolved without breaking partners. A handful of rules worth following from day one:
- Version from the start. The path is
/api/v1/products, not/api/products. Adding v2 a year later costs two lines of code. Without versioning — it costs renegotiating contracts with partners. - One endpoint = one resource.
/api/v1/productsreturns products,/api/v1/stockreturns stock. Don't mash everything into a single "master endpoint" just because "it's easier on the ERP side". - Idempotency wherever you write. The partner sends an order with their own external order number. If they send it twice — same result, but no duplicate order is created. Without this, your first complaint will be "I sent it once, you have it twice, who's paying?".
- Concise responses, no internal IDs. Return SKU, EAN, name, price — not
ProductGuid,WarehouseZoneRefIdand other internal fields. Your internal structures will change; the contract with the partner shouldn't. - Docs generated from code. Swagger/OpenAPI bundled with the service. "We'll write docs when we have time" is the same as "we'll never write docs", and without them partners will email you about every field.
Security — what actually to watch
Three things that in practice separate an API that runs without incident from one that ends up on a paste site:
- HTTPS enforced, HTTP redirected. No exceptions, including in staging. An API key sent over HTTP is a public key.
- Rate limiting per key. Even if you trust the partner, 5–100 requests/minute protects you against a bug on their side. We've seen a partner's script that, due to a recursion error, was firing 3,000 requests/minute — without a limit it would have taken the service down.
- Key rotation every 6–12 months. Trivial, almost never done. Put it in the partner contract and email a reminder a month ahead. A key that hasn't been rotated in 4 years and was once in an email to a former employee isn't a key — it's an invitation.
Add the healthy minimum: an audit log of all requests with 90-day retention, an alert on unusual traffic (a sudden 10x spike), and separate ERP accounts for API operations — ones that physically have no rights to modify customer records, payroll or bank data. The API reads and (in a narrow scope) creates orders. Nothing more.
Where to start
If someone in your company has started saying "we want an API to the ERP", do this in order:
- Write on one page who is asking for what, specifically. Not "partners", but three specific customers and specific data. Without this you're designing an API for a future that never arrives.
- Count the hours. How many hours a week do you lose on those three requests today? Multiply by 50 weeks. That's your budget ceiling.
- Pick at most 4 endpoints for the first release. Stock, pricing, one-way order intake, status. The rest waits for v1.1.
- Decide on the middle layer. Even the simplest API needs a middleware — don't try to expose Optima "over SQL". A plain .NET service with a Redis cache is enough for most SMEs for the first two years.
- Plan 2–4 weeks for the MVP, another month for docs, monitoring and onboarding the first partner. Don't plan "for six months" — an API designed for six months never goes live.
A custom API over your ERP isn't a vanity project "because they have one in the corporate world". It's the answer to a specific hour of a sales rep's week that's currently being lost to replying to emails. If those hours add up to 5 or 10 a week — the project pays back within a quarter and then works on its own for years.
If you want to check whether this is the moment for your company but don't have a month for analysis, we help SMEs break this down in a 30-minute call. No slides.
An API for your ERP isn't a vanity project. It's the answer to an hour a week that's currently being lost to replying to the same email.