Integration reference

What this page covers

Bulutegra is an integration layer: it sits between the marketplaces, your own website and your ERP. We build the connection and absorb the differences on the channel side, so you work in one panel instead of learning each channel's technical quirks.

Of the 47 integrations listed on this site, 22 have a connection that is built and running; 25 are set up on request. This says what the product supports. It says nothing about who sells on which channel.

The service addresses in the tables are the official seller services published by those systems. Bulutegra connects to them on your behalf, with your account's permissions. There is no Bulutegra endpoint in between.

No key, password, seller number or sample credential appears in these tables. The column "What we need from you" only names which detail is required.

Marketplaces

Every marketplace connection runs over that channel's own seller service. Orders are read from the channel; stock, prices and listings are written as far as the channel supports it.

Scroll the table sideways to read it.

When the "Written" column says "Decided during onboarding", the write direction for that channel is opened according to your account's permissions and the shadow mode results. Write access is never switched on for every channel at once; it is opened channel by channel.

Stock is managed from a single pool across all channels: a sale on one channel reduces the quantity on the others. There is no separate stock ledger per channel.

E-commerce platforms

If your own website runs on an e-commerce platform, its products, stock and prices join the same pool, and the site behaves like one more channel.

Scroll the table sideways to read it.

Where no ready-made connector exists there are two routes: the platform's own official API, or a regular XML/CSV feed. Which one applies depends on what is available in your edition, and is decided during onboarding.

The ownership flag applies here too: for a given product and channel it is clear whether Bulutegra or an outside system is in charge, so two systems never update the same field in opposite directions.

ERP

An ERP connection always follows the same order: read first, then compare, and write last. On the ERP side writing stays separate and supervised, because a wrong record travels all the way into the accounts.

Scroll the table sideways to read it.

For Logo, Mikro and SAP the connection depends on the customer's edition and the modules that are licensed, which is why we call it set up on request rather than ready. Tell us your edition and modules and we will say up front what is possible.

Supplier feed

If you do not make the products yourself but buy them from a supplier, the catalogue is read from a feed file.

Scroll the table sideways to read it.

The fields are read from fixed columns. Prices are calculated with a multiplier per supplier, and stock below the agreed threshold is not put on sale.

This is where the bulk-zeroing brake matters: if an abnormal number of product codes would be zeroed in one pass, sending stops and an alert is raised. A broken or half-downloaded feed cannot empty every channel.

Carriers

A marketplace order arrives together with its carrier and delivery method. That detail is defined per channel and is written to the ERP along with the order.

Scroll the table sideways to read it.

A direct connection to a carrier's own service is set up on request, and its scope is decided during onboarding. That is why every row here says set up on request: we do not present a connection that has not been built as if it were ready.

Social and advertising channels

These three systems are listed as part of the channel universe shown on this site.

Scroll the table sideways to read it.

For all three the connection is set up on request; the scope and the details required are decided during onboarding.

Four rules that apply to every connection

Shadow mode. Onboarding reads only at first. Data is pulled from both sides and compared, and nothing is written anywhere. You see what would happen before you hand anything over.

Channel-by-channel handover. Write access is not switched on all at once. Each channel goes live on its own, and the matching and the data behind it are checked before that channel starts writing.

A single stock pool. Stock is managed in one place. A sale on one channel reduces the quantity on the others.

The bulk-zeroing brake. If an abnormal number of product codes would be zeroed in one pass, sending stops and an alert is raised. There is no quiet pass that empties every channel.

What we need from you to connect

The column "What we need from you" lists the credentials you create in that system's own panel. They belong to your account, and Bulutegra uses them only on your behalf.

Do not type credentials as plain text into the contact form or into an e-mail. We agree how each detail will be handed over during onboarding, and we write down why each one is needed.

Keys are held on the server in files that only the user the service runs as can read, and they are never shown in readable form in the panel. For Etsy and eBay the connection is made with a one-click authorisation; withdraw that authorisation in your own account and the connection stops at that moment.

What we do about storage, backups and disk encryption — and what we do not do — is written plainly on the security page: Security, access and data protection.

A system that is not on the list

If a marketplace, platform, ERP or carrier you need is missing from these tables, the connection is set up on request.

The first question is always the same: does that system publish an official seller service or a regular XML/CSV feed, and is it available on your account? If it is, the connection follows the same order: read first, then shadow mode, then writing channel by channel. If it is not, we say up front what cannot be done.

We make no promises about timing on this page. Once the scope is clear we share the schedule in writing.