invent.sale
trust

What happens to your network's data

We see a network's turnover, its suppliers and its purchase prices. This is one page about who can do what with that data, where it is stored, and where to write if you have found a hole.

what is missing here

We hold no certifications and will not draw badges. Below is only what you can verify inside your own tenant: access settings, the action log, and keys you revoke yourself.

What we commit to doing with data

A network's data stays the network's

We do not sell it, do not fold it into a market data product and do not use it for other clients' analytics — anonymised extracts included. Anonymised turnover by category still names the size of the network.

Integration starts read-only

We connect to the accounting system read-only. Write-back is a separate client decision, a separate setting and a separate conversation — not a side effect of onboarding.

Taking your data out needs no conversation

A read key and file exports exist from day one: data marts as CSV, orders as XLSX. Leaving us must not depend on our willingness to export something.

Retention lives in the contract, not in website copy

How long backups live and what happens to data after termination is fixed in the contract with the specific network. We are not going to invent a tidy number for a web page.

Roles and access

One rule: anything that can leave the tenant is switched on by the network owner, not by us during onboarding.

Each network has its own tenant

Its own database, keys and schedules. One client's request cannot technically reach another's data — this is separated storage, not a permission checkbox.

The owner enables anything that leaves

Automatic order sending, write-back to accounting, a public read key — the network owner switches each of these on and off. Large orders can stay on mandatory confirmation.

No key grants write access

A public key is scoped to its client's data and works read-only. It is revoked by the owner at any moment, without asking us.

The log cannot be edited from the interface

Who edited an order, who sent it, to whom and when. A log you can tidy up with a button proves nothing — so there is no such button.

An engineer sees data while fixing things

The team is small, and the people who write the calculation are the ones who investigate failures. We do not hide it: during an incident an engineer works with the network's data, and actions in the interface land in the same log as the client's own.

How to report a vulnerability

If you have found a vulnerability, write to komron@invent.sale. A description of the steps and what you got is enough: a screenshot, the request, the server response.

A person answers, not a form

The message is read by someone who can change the code. We confirm receipt and say whether we reproduced it — even when the report turns out to be a false alarm.

We warn the client if it concerns them

A network owner hears about a problem affecting their data from us, not through someone else's retelling. What was possible and what we did — with no softened wording.

Do not test against live tenants

Behind the data are working pharmacies and stores: an order that goes out to a supplier during your test arrives on a truck. If you need an environment, ask and we will arrange one.

Who we share data with

With nobody except those the network itself addresses, and only within the limits it sets.

To other clients — never

One network's data never enters another's calculation, report or training set. That is not a future policy but a consequence of separated tenants.

To a supplier — only their order

A supplier sees the order addressed to them and its history. Not the network's stock, not other suppliers' prices, not what the network orders elsewhere.

To contractors — on your decision

If a network wants to hand data to its integrator or consultant, it issues a read key itself. We are not a middleman and do not grant access on its behalf.

The messenger is a deliberate choice

When an order reaches a supplier through a messenger, the contents of that order pass through the messenger. We say so before launch: the alternative is a file by email, which is slower and read less often.

Where data is stored

In the platform's database, not in third-party services

Data sits on the platform's rented servers. We do not forward a network's exports into third-party analytics services or wire trackers into them.

The hosting location is named in the contract

The specific data centre and country are named when the contract is signed, along with retention terms. On a website it would be a promise that is hard to verify.

Files from the accounting system live in the client's tenant

The nightly export lands in that client's directory and feeds the calculation from there. There is no shared directory holding every network's files.

In more detail

Security

Data access and responsible AI in detail

Privacy

What we do with shopper data

Platform status

How we report failures

Changelog

What changed in the platform, and why

API and formats

Read key, webhooks, exports

Results methodology

How effect is measured, and when we refuse

Show us one critical process. We will show how it runs here.

We look at your cycle: how an order is assembled today, who decides, where time leaks and what the system takes over.

Start with one critical process

Connect replenishment, supplier ordering or another first workflow, then expand across one platform.

Trust Center — invent.sale