It plugs into what you already run.
ERP, PIM, WMS, CRM, payment gateway, carrier, e-invoicing, language model, search engine, file storage, ad tags and product feeds: each of those has its own documented entry point here. Not a nightly file export, but a partner API, signed webhooks and encrypted vendor configurations.
- REST
- partner API with a live OpenAPI document
- HMAC
- signed webhooks with retries
- 3
- payment gateways out of the box
- 4
- language-model providers
Three ways to connect a system
There is no single “integrates with everything”. There are three well-documented mechanisms, and an integrator picks the one the job needs.
API keys and the partner API
A bearer token with a narrow set of scopes, optionally bound to one organization and one sales channel. Everything an integration does happens on a namespace dedicated to partners.
- Separate scopes for catalog reads and writes, and for reading and placing orders
- A key bound to an organization sees its prices and limits, and nothing beyond that
- The token is shown once; only its hash is stored in the database
- Stepping outside the granted scope is refused and written to the audit log
Webhooks
Events reach your system the moment they happen: signed, retried, and replayable after the receiver comes back up.
- An HMAC-SHA-256 signature computed over the raw request body
- Up to eight attempts with growing backoff and a timeout per attempt
- Failed deliveries land in their own view with a manual replay button
- A subscription can be narrowed to the events of a single organization
Vendor configurations
Credentials for gateways, carriers, analytics or CRM kept in the admin panel: encrypted, tested on save, and never returned in plaintext.
- AES-256-GCM encryption with the key held outside the database
- A connection test that runs as soon as the configuration is saved
- Status and the last error message shown next to the integration
- Readable only through the adapter that genuinely needs them
Integration catalog
Some of these connections work the moment you enable the module. The rest are entry points where an integrator wires in a specific system, without modifying the platform core.
Payments
From a plain bank transfer to a card gateway with 3-D Secure and refunds initiated from either side.
-
Stripe →
A full gateway integration: cards, BLIK, Apple Pay and Google Pay, 3-D Secure, payment embedded in the checkout page or a redirect to Stripe Checkout, saved cards, and refunds initiated both from the platform and from the Stripe dashboard.
-
PayU →
A PayU GPO integration: BLIK, cards through the PayU Secure Form, Apple Pay, Google Pay and pay-by-link, checkout as a redirect or embedded on your own page, saved cards and BLIK One Click, notifications verified by the OpenPayu signature, and refunds through the returns module.
-
tpay →
A tpay Merchant Open API integration: BLIK, cards, bank transfers, checkout as a redirect or on the shop’s own page, saved cards and BLIK One Click, JWS-signed notifications, and refunds through the returns module.
-
Bank transfer
The order waits for the transfer, the operator marks it as paid in the admin panel, and the order status moves according to your own rules.
-
Cash on pickup
In-person collection and cash payment, with no gateway in the loop at all.
-
Credit limit
Pay-on-invoice within the limit granted to the organization, with funds reserved atomically at the moment the order is placed.
-
Further gateways
Gateways such as Przelewy24, PayPal or Autopay are added exactly the way Stripe, PayU and tpay were built: a new adapter module registers the driver and the payment method, and the platform core stays untouched.
Delivery and logistics
Carriers, dispatches and stock levels as documented contact points with logistics systems.
-
Carrier adapters
Delivery methods come from adapter modules. Enabling a carrier adapter creates a configurable delivery method visible at checkout on its own.
-
Dispatch and tracking
Every dispatch attempt is a separate shipment record with the carrier reference, status, failure reason and a retry that does not touch the order.
-
Warehouse systems
Multiple warehouses, reservations and warehouse-to-channel assignments are exposed through the API and events, so a WMS can remain the source of truth for stock.
ERP, PIM, WMS and CRM
The integration that matters most in B2B: the platform and the system the company actually runs on.
-
Comarch ERP Optima →
The most widely used ERP in Polish small and mid-sized companies. Product records, stock, prices and sales documents are wired up with an adapter built on the partner API and webhook events. We agree the scope and the direction of each sync during the workshop.
-
Subiekt GT →
Insert’s sales and warehouse system, common in wholesalers and trading companies. Products, stock levels and orders synchronise through the partner API, and sales documents flow back into Subiekt in the agreed format.
-
Partner API
A namespace dedicated to integrators: product list and detail, the category tree, prices and orders. It is the only surface meant for external systems, which is exactly why its contract stays stable.
-
Catalog synchronisation
Product upsert by SKU for PIM systems, plus incremental pulls of everything changed since a given timestamp, with cursor pagination for large catalogs.
-
Bulk pricing
A single request prices up to two hundred lines for a specific organization, guaranteed to match to the cent what the cart would charge.
-
Idempotent ordering
Orders placed with an idempotency key: repeating the same request returns the same order, never a second one. The same holds for concurrent replays.
-
The organization capability envelope
An integration can never do more than that company’s own buyers. The same credit limits, allowed payment and delivery methods and channel assortment apply, there is no parameter that bypasses the rules.
-
Business events
Order creation and status changes, quote requests, payment settlements, credit-limit adjustments and product changes go out as versioned webhook events.
E-invoicing and accounting
Sales documents that satisfy Polish requirements and are ready to hand over to a finance system.
-
KSeF →
Invoices and corrections submitted to Poland’s national e-invoicing system in the FA(3) format through a durable queue. The KSeF number lands on the document, the official confirmation is downloadable, and the PDF gains a verification QR code.
-
PDF invoices
Proformas and invoices generated after order confirmation, with your own numbering scheme and file access through the API.
-
Handover to accounting
Orders, invoices and payments are available through the API and webhooks, so pushing documents into a finance system is a matter of an adapter, not a platform change.
Artificial intelligence
You connect the language model on your own key, and you decide whose model it is.
-
OpenAI (GPT) →
GPT models as the engine behind the admin assistant, running on your own API key with the model you name in the configuration.
-
Google Gemini →
Gemini models as an alternative to GPT, configured in the same place and just as swappable without a code change.
-
Anthropic Claude →
Claude models for handling natural-language instructions, picked from the same provider list as the rest.
-
DeepSeek →
DeepSeek models for deployments looking for a cheaper option, or one less dependent on the largest providers.
-
Semantic search
Search can compute embeddings against any OpenAI-compatible endpoint, including Azure OpenAI or a locally hosted Ollama, if the data must never leave your infrastructure.
-
Shared credentials
Keys are stored once, encrypted. Replacing a key in one place takes effect immediately in every module that uses it.
Search
A dedicated search engine, not a SQL query with a LIKE clause.
-
Meilisearch →
An index built separately for each sales channel and kept current by catalog events, serving search, attribute filtering and type-ahead suggestions.
-
Hybrid mode
With semantic search enabled, the same index combines classic phrase matching with meaning-based matching, separately per channel.
Email and messaging
Transactional and bulk email travel through separate channels, on the providers you choose.
-
SMTP
Any mail server as the sender of transactional messages, with credentials held in an encrypted configuration.
-
Amazon SES →
Delivery through SES with its own credential set, picked from the same list as every other provider.
-
SendGrid →
Delivery through SendGrid on an API key, with no code change in the modules that send messages.
-
Newsletter
Bulk sending runs on its own SMTP channel (SES SMTP, Mailgun or any other relay), independent of transactional email. The whole module can be switched off if you use an external mailing platform.
Analytics and advertising
Buyer-behaviour data both on your side and in the tools your marketing team already uses, behind one shared cookie consent.
-
Google Analytics 4 →
A switch and measurement ID per sales channel, Enhanced Ecommerce, a configurable custom-events builder and optional server-side tagging.
-
Google Tag Manager →
A GTM container per sales channel, with a stable commerce event vocabulary on the data layer and Consent Mode v2. Turn server-side tagging on and the same events are delivered from the backend to your server container: exactly once, never down both paths at the same time.
-
Meta Ads →
A Meta Pixel per sales channel with the standard commerce events: ViewContent, AddToCart, InitiateCheckout, Purchase and Lead. Your own event names are added alongside the standard ones, so a B2B-specific audience never costs you purchase reporting.
-
LinkedIn Ads →
An Insight Tag per sales channel and mapping of storefront actions onto conversion IDs from Campaign Manager. Only actions the platform actually emits can be mapped, there is no entry that could never fire.
-
Cookie consent
One banner and one stored decision serve every tool at once. Until the visitor accepts, no script, cookie or request goes out, and each tool is switched on and off independently of the others.
-
Your own event log
Storefront events collected on your side with summaries in the admin panel, regardless of whether any external analytics tool is enabled.
Product feeds and marketplaces
A sales channel’s catalog published in the format a shopping engine or a marketplace expects: no manual export, no spreadsheet on someone’s disk.
-
Google Merchant Center →
A ready-to-use XML template at variant level, complete with the fields Google requires. The file sits at a stable, tokenised URL that Merchant Center fetches on its own, on your schedule.
-
Meta catalog →
The second ready-to-use template, in Meta’s product-catalog format, using the same generation, scheduling and publishing mechanism as the Google feed.
-
Marketplaces
Starting-point templates for Amazon, eBay and Allegro (TSV and CSV) carrying identity, price, availability, link and image. Account-specific fields are added in the template editor: in this version it is a file to fetch, not a marketplace API integration.
-
Product taxonomies
Google’s and Meta’s own category trees ship with the platform (over 8,500 nodes, in English and Polish), so generating a feed never depends on reaching the provider. A newer revision is installed inactive, and an operator promotes it after previewing what it would change.
-
Pricing and narrowing
A feed is priced net or gross, from a named price list or the channel’s anonymous resolution, and its assortment is narrowed with the same rule builder as promotions, with a live match count computed from the very prices the file will carry.
-
Control over the link
The feed URL can be rotated or revoked with immediate effect, every run records per-item skip diagnostics with a CSV export, and a failed run notifies once: on the transition into failure, not on every attempt.
Files and infrastructure
The components the platform runs on: standard, swappable and self-hostable.
-
Amazon S3 →
Images, documents and attachments stored in S3, with public or private visibility set per asset.
-
Google Cloud Storage →
The same storage model on GCS, switched from settings without a code change.
-
Local disk
The default option, convenient for on-premise deployments and development environments.
-
PostgreSQL →
The database the catalog, orders, prices and everything else live in, a standard installation you can host yourself.
-
Redis and job queues →
Session cache plus the queues handling webhooks, email delivery, search indexing and e-invoicing submissions, with retries and a view of failed jobs.
Sales channels
A marketplace, a distributor portal or in-store sales as further channels of the same platform.
-
Distributor portals
Every place of sale is a separate channel with its own assortment, prices and content. An API key bound to an organization and a channel serves integration traffic on exactly the same terms as a buyer.
-
Apps and POS
The same backend and the same API serve the mobile app (PWA) and in-store sales, with no parallel system to build.
What you can expect from every integration
These are rules shared by the whole integration layer, not promises made separately for each system.
A live OpenAPI contract
The OpenAPI document is generated from contracts held in the code and is the source of truth for every endpoint. Integrators do not guess formats or work from an outdated PDF.
A replay never creates a duplicate
Order placement requires an idempotency key, and webhook receivers get a stable event id to deduplicate on. Sending the same thing twice never doubles an order.
The API price is the price
A quote fetched through the API runs through the same pricing engine as the cart and the order. It matches to the cent, so the integration does not generate complaints.
Failures are visible
Failed webhook deliveries have their own view in the admin panel with a replay button, and a failed connection test leaves the error message next to the integration configuration.
Secrets do not leak
Tokens are stored only as hashes, vendor configurations are encrypted, values are masked on read, and audit-log entries are redacted.
Every request is traceable
Responses carry a request id: the same one that reaches the logs and the audit log. Quote it in a ticket and the whole path can be reconstructed.
Looking for your industry? Browse all industries →
Your system is not on the list?
That is good news, because this is exactly the point. The list of integrations is not closed: a new payment gateway, carrier, ERP or BI system is another adapter module that registers itself with the platform and gets its own settings and permissions. The core stays untouched and the code lives in your repository. During the workshop we go through the systems you actually run and decide which of them make it into the first rollout.
Let’s find out what we can connect at your end
Book a free workshop. We will walk through your ERP, warehouse and sales processes, and show you what the integration path looks like step by step.