How it works

From setup to steady state: data in the ERP is normalised in the panel, converted into the shape each channel expects and pushed through a queue. Orders coming back from a channel are written into the ERP along the same path.

1 · Connect the ERP and the channel

You connect your ERP and each sales channel with its own credentials; channel-specific settings are entered in the panel, with no software update to wait for. One channel can be marked the master, making it the reference for product data.

The connection is tested before anything is saved
The panel warns when a key is about to expire
Several storefronts can hang off the same ERP

2 · Approve the mappings

The channel’s category tree and attribute schema are pulled in, and the platform reads your existing product data to propose mappings. What you approve becomes permanent; nothing that stays a suggestion is ever pushed on its own.

Category, brand, attribute and option mappings
Required and optional attribute counts per category
Attribute aliases resolve “ANTRASİT” once and for all

3 · See what can be pushed, before pushing

Before a push starts, every product gets its own reason: no category chosen, a required attribute missing, no image, product inactive. Nothing drops silently — you fix the list and run it again.

How many of 1,845 products are ready, on one screen
A fix link next to every blocker
The report is kept per channel

4 · The flow runs, every step is recorded

Stock and price changes are queued and sent to the channel in batches. A push that hits the channel’s rate limit is not lost; it waits a moment and is retried.

What every operation sent and what it got back is stored
You see how long each job took and how it ended
Channel, ERP and error logs can be reviewed separately

Under the hood

Three-layer integrations

A transport that talks to the outside system, a format layer that translates between internal data and the external shape, and a mapping layer holding category and attribute equivalents. One channel’s quirks never leak into the others.

In practice: A change or outage on one channel’s API does not spread to the others.

Sync and async

Light work runs directly from a command. Heavy work — product transfer, stock and price updates, translation, Excel jobs — is written to a queue and handled by consumers.

In practice: You keep working in the panel while a bulk push runs.

Channel settings

Channel-specific settings live in a free-form field. A new setting needs no database column; the integration reads it from its own JSON.

In practice: A channel’s special needs are met without touching the rest of the system.

Rate limits

Channel API rate limits are respected in the integration layer. A request that hits the limit is backed off and retried, which is why bulk pushes run on the queue.

In practice: A push that hits a channel’s rate limit is not lost; it completes when its turn comes.

Technical questions

How it behaves

Common questions about what runs behind the integration.

What happens to edits made on the channel?

Channel-to-panel synchronisation runs as its own direction, reading changed products back into the panel. Which direction wins is decided at setup.

How long does adding a new sales channel take?

Queueing, logging and error handling are already in place for every channel; a new one only needs its own connection and mapping. How long it takes depends on how much the channel’s API covers.

What happens when a transfer fails?

Pushes run as batches whose results are stored, and recurring failure patterns are kept separately. Failed records are listed and can be sent again.

Which databases does it use?

Business data sits in MySQL and the high-volume record stream in MongoDB, so log volume never slows the business queries down.

Technical notes

How it works

Short reasons behind the design decisions.

Why are stock and price on separate queues?

Stock changes within seconds, price usually a few times a day. Separate queues stop the price job from holding up the stock flow.

When is an order written to the ERP?

It is stored as soon as it reaches the panel; writing it to the ERP is a separate step, and the status history stays on the order record.

Where are the records kept?

Platform, command, consumer, ERP, exception and audit records live in separate MongoDB collections; variant changes have their own.

See it with your own data

In a free demo we show Orventory with your ERP and channels. After the call you get a firm quote for setup and the monthly subscription.

Book a free demo