A meeting at the client's office, a room with a projector, and on the table a stack of Allegro orders printed out to be retyped. The owner says: "Every system has an API these days. You'll hook it up in a week." The IT guy nods. I ask which version of Subiekt nexo they have and whether it includes Sfera. The other side of the table goes quiet.
That silence is nobody's fault. Subiekt nexo (a Polish ERP by InsERT) is a solid sales and warehouse system, it just isn't a web service. There is no address you can send an HTTP request to and get an invoice back. What it has instead is Sfera, and that is where every honest conversation about integration starts. Below are seven things that surface too late in Subiekt nexo integration contracts, and how we defuse them in our projects.
What Sfera is and why it changes the whole architecture
Sfera is InsERT's programming interface for the nexo line. In practice it is a set of .NET libraries you load into your own program and use to work on Subiekt's objects: documents, products, customers, price lists. Your code opens a session, much like a user logging into the program, and performs operations on Subiekt's side, with its validation and its numbering. Sfera is available in nexo PRO. If you have the standard nexo, that is the first thing to check in InsERT's documentation or with the partner who sold you the license.
This changes the architecture more than you might expect. A typical Allegro or WooCommerce integration lives on a cloud server: a webhook comes in, the code does some work, passes it on. With Sfera that is not possible. The libraries have to run on a Windows machine with Subiekt nexo PRO installed and access to its database. So the integration needs a "foot" planted next to Subiekt: a Windows service that listens, queues and writes. The cloud can handle the rest, but the last metre is always local.
In our projects it usually looks like this: the part that receives events from the marketplace and the online store runs as a service that can be hosted anywhere, while the part that talks to Sfera sits on the client's server, next to Subiekt. Between them there is a queue and an operations log. More on that in a moment, because it is what defuses two of the seven traps.
A Subiekt nexo integration is not a webhook. It is a program that lives next to Subiekt and works on its terms: with its numbering, its validation and its license.
Seven traps that surface after the contract is signed
The order is deliberate. The first three concern the environment and licenses, the next three data and events, and the last one what stays in the company once the project is over. I describe each the same way: what happens, how it hurts and how we solve it.
Trap 1: there is no REST API, there is Sfera, the PRO edition and Windows
What happens. The integrator prices the project like an ordinary connection between two APIs. After the contract is signed it turns out you need to buy the PRO edition, designate a Windows machine next to Subiekt and decide who maintains it. The deadline slips, the budget grows, and nobody feels responsible.
How we solve it. We ask about the Subiekt version and Sfera in the first conversation, before quoting. In the audit we describe where the Sfera service will run, who has access to it and how it is monitored. Only then do we give a price and a deadline. If the company has the standard nexo and has no plans for PRO, we say so plainly and work out together whether the upgrade is worth it at all.
Trap 2: a Sfera session is a workstation
What happens. The integration logs into Subiekt like a user. In our projects we treat it as an additional workstation and plan the license purchase accordingly. If nobody counts it, on Monday morning someone in the office cannot log in because the integration "took a seat" overnight and never released the session.
How we solve it. The service holds a single session, opens it only while working and closes it after each batch of orders. You settle the number of workstations before the rollout, not after. Exactly how your license counts Sfera sessions is something to confirm with InsERT or your partner, because the terms can differ between packages and versions.
Trap 3: a Subiekt update versus the Sfera library version
What happens. The Sfera libraries are tied to the program version. The accountant clicks "update" on a Friday afternoon, Subiekt comes back up in the new version, and the integration service stops connecting because it was built against the previous one. The weekend's orders sit in the queue, and on Monday nobody knows why.
How we solve it. A Subiekt update goes in the calendar, not down to chance. We check library compatibility on a copy of the database, rebuild the service and only then update production. The support agreement states who does this and within what time. Without support you get step-by-step instructions and a repository from which your IT person can build the new version.
Trap 4: receipt or invoice, ZK or FS, OSS and currencies
What happens. "Push the order into Subiekt" is a sentence that means nothing in a contract. An order from a consumer on Allegro is a different document from an order from a company with a VAT ID. One ends in a receipt, the other in an invoice, and sometimes in an invoice issued against a receipt. A sale to a consumer in another EU country may go through the OSS procedure at the VAT rate of the destination country. Amazon pays in euros, Subiekt posts in zloty. Each of these cases is a separate path, and an integrator who hasn't written them down will discover them together with the accountant at month end.
How we solve it. Before writing a line of code we draw up a document map. Which orders come in as ZK (sales orders) and when they turn into FS (sales invoices), when a receipt is created, what an invoice against a receipt looks like, which day's exchange rate we use and where the VAT rate for EU sales comes from. That map is part of the audit document and it is signed off by the accounting team, not by us.
Trap 5: stock levels, reservations and queries during business hours
What happens. The store shows the stock level from Subiekt but ignores reservations from open ZK orders, so it sells goods someone has already bought. Or the company has several warehouses and the integration adds them all up, including the one for returns. Or a stock refresh every minute queries the whole database, and at ten in the morning Subiekt starts slowing down on every workstation.
How we solve it. We calculate available stock, meaning stock level minus reservations, and agree with the client which warehouses count towards sales in a given channel. Stock changes are sent incrementally, only for products that have actually changed, and heavier operations are scheduled outside office hours. Before anything goes to production, we measure the load on a copy of the database.
Trap 6: the same order twice
What happens. The marketplace sends a new-order event, the integration saves a ZK, and a moment later the same event arrives again. Because the network blinked, because the status changed, because someone clicked "sync". The result: two documents for one order, two reservations, two invoices and one very angry accountant.
How we solve it. Every event gets an idempotency key built from the order ID and the channel. Before anything reaches Sfera, we check the operations log to see whether that key has already gone through. Events wait in a queue, so when Subiekt is unavailable nothing is lost, it just waits. The log is human-readable, so that on Monday morning someone can answer the question "what happened to order number such-and-such".
Trap 7: whose code is it when the subscription ends
What happens. The integration works, the subscription invoice arrives every month, everyone is happy. Two years later the company wants to switch vendors or add a single rule, and it turns out the code is on the contractor's server, the configuration is in their panel, and there is no documentation. The only way forward is to write it again from scratch.
How we solve it. The code and configuration belong to the company that paid for them. The repository is at the client's or in a place they have full access to. The documentation describes the architecture, the document map and the update procedure. Support is an option, not a condition for the system to work. The exact scope of the rights transfer is written into the contract, as we describe in our FAQ.
The operations log: what an integration looks like from the inside
The best test of an integration is its log. If after an overnight run you can say within a minute how many orders came in, how many were skipped and why, the system is under control. Here is a sample excerpt from the log of our service. The numbers are an illustration, not statistics.
[21:04:11] run #1842 started (allegro:account-1, allegro:account-2, woocommerce)
[21:04:12] fetched 37 orders (allegro:account-2)
[21:04:12] fetched 12 orders (allegro:account-1)
[21:04:13] fetched 5 orders (woocommerce)
[21:04:13] skipped 2 duplicates (idempotency-key)
[21:04:14] Sfera session opened (nexo PRO, workstation: integrator)
[21:04:15] customer K-000731 exists, creation skipped
[21:04:16] ZK/2026/09/0928 created (allegro:account-2, 4 lines, reservation)
[21:04:17] customer created: K-004412 (VAT ID verified)
[21:04:19] FS/2026/09/0412 created (allegro:account-2, EUR -> PLN, daily rate)
[21:04:20] PA/2026/09/2201 created (woocommerce)
[21:04:26] stock: 118 products changed, pushed to 3 channels
[21:04:28] error: no VAT rate for destination country
[21:04:28] order A2-55910 moved to the queue
[21:04:29] Sfera session closed
[21:04:29] run #1842 finished: 52 orders, 2 duplicates, 1 to clarifyThree things to notice. The Sfera session lives for a few seconds, not the whole night. Duplicates are counted, not swept under the rug. An order the integration cannot post does not vanish and does not create a wrong document; it goes to the queue with a description the accountant will understand.
Sfera nexo, Sfera GT or a subscription integrator
The owner usually asks: "wouldn't it be simpler to get an off-the-shelf integrator?" Sometimes it would. Below is a comparison of the three ways orders can get into Subiekt. Confirm the licensing details of Sfera, for both nexo and GT, in InsERT's documentation, because it is their product and their terms.
| Criterion | Sfera nexo (your own code) | Sfera GT (your own code) | Subscription integrator |
|---|---|---|---|
| Where it runs | A Windows service next to Subiekt nexo PRO; the rest can live in the cloud | A program next to Subiekt GT with Sfera GT; in our projects it requires Subiekt running on that machine | The vendor's cloud; it usually connects to Subiekt through the vendor's agent installed next to the program |
| Who maintains it | You, or a company of your choice; support is an option | As above | The vendor, as part of the subscription |
| What happens on a Subiekt update | Library compatibility test and a service rebuild, scheduled in the calendar | As above; the interface is older than in nexo, so pick a contractor with experience specifically in GT | You wait for the vendor to release a compatible version; usually quick, but out of your hands |
| Who owns the code | You, once the implementation is paid for | You, once the implementation is paid for | The vendor; after you cancel, you keep whatever data you manage to export |
| Who it is for | Custom rules: several accounts, B2B alongside B2C, OSS, multiple warehouses | Companies staying on GT that have their own rules | A standard store, one channel, typical documents |
Scroll the table sideways
When an off-the-shelf integrator is enough
Not every company needs its own code. If you sell on a single Allegro account, every order ends in a receipt or a simple invoice, you have one warehouse and no plans to sell abroad, a subscription integrator will do the job. You pay monthly, the vendor keeps it compatible with Subiekt, and you don't maintain any server.
A custom integration starts to pay off when the rules no longer fit in a configurator: several accounts and marketplaces, B2B alongside B2C, OSS, several warehouses, your own pricing or reservation logic. Then every month on an off-the-shelf tool means workarounds, manual fixes and explaining to the accountant why a document looks different from how it should. We worked out what such workarounds cost in hours in a separate post.
Checklist: 9 questions for your integrator before signing
Email this before the meeting. A good company will answer each question in a few sentences. A weak one will start with "it depends" and stop there.
- 01Which version of Subiekt nexo does your quote assume, and is Sfera available in it? Who checked?
- 02Where physically will the part of the integration that talks to Sfera run, and who maintains that machine?
- 03How many workstations or sessions does the integration use, and have you included that in the license count?
- 04What happens after a Subiekt update: who checks library compatibility, within what time and at what cost?
- 05What does the document map look like: which orders go in as ZK, which as FS, when a receipt, when an invoice against a receipt, how do you handle OSS and currencies?
- 06How do you calculate available stock: do you subtract reservations, and which warehouses count towards sales in a given channel?
- 07What happens when the same order arrives twice? Show us the operations log from your tests.
- 08Where are the code repository and the configuration, who has access to them, and what do I get if we end the cooperation?
- 09Before going live, do you run the integration on a copy of my database, and who reviews the result together with the accountant?
What we did with this knowledge
We know most of these traps from our own projects, not from theory. For a seller on five Amazon EU marketplaces we built a C# .NET desktop application that, through Amazon SP-API and Sfera, creates an invoice in Subiekt nexo PRO for every order, split by country and with transaction classification. The application runs on the same machine as Subiekt, remembers the ID of every Amazon order so it never creates a document twice, and passed the Amazon security review. From kick-off to production took 3 weeks. For a home-appliance wholesaler with four price lists and 1,293 products we connected a tablet app, a B2B portal and Subiekt nexo into a single data flow, in stages of 2-3 weeks each. The .NET 8 integration hub sits next to Subiekt and talks to it through Sfera, and an order resent after a loss of signal is recognized as a duplicate, so only one document ends up in Subiekt.
- Amazon EU marketplaces in one Subiekt nexo PRO
- 5
- of VAT invoices with no manual work
- 100%
- a month given back to the B2B wholesaler
- 180h
In both cases the code is owned by the client and there is no subscription to a middleman. Subiekt updates are scheduled, not accidental.
