To answer a marketplace customer properly, a support tool needs access: to the marketplace’s orders and messages, to your shipping platform, to your mailbox, maybe to your invoicing. Each of those is an API key or an account login, and each of them is powerful. A Mirakl API key is not read-only. It can accept orders, ship them, and refund them. A shipping platform key can create labels billed to you.

So the question is not whether a helpdesk can do the job. It is whether it can be trusted with the keys that make the job possible. These are the ten questions we would ask any tool, including our own, and the answers we think are the minimum.

1. Where do the keys live, and how?

The only acceptable answer is: encrypted at rest, with a key the application holds separately from the database, so a copy of the database alone is useless. Ask whether the encryption key can be rotated without downtime, and whether it has ever been.

A tool that stores your API key in plain text in a config column is a breach waiting for a backup to leak.

2. Can I ever see the key again?

No. Once entered, a secret should never be shown, in the UI or in an API response. The tool can tell you a key exists, when it was set, and whether it works. If a product shows your Mirakl key back to you in a settings screen, it is stored in a way that can show it to someone else.

They probably do; that is how SaaS works. The question is whether the isolation is tested. Every endpoint that touches a case, a connection, a setting or an export has to refuse (ideally with a 404, not a 403, so it does not confirm the thing exists) when the caller is not a member of that workspace. Ask whether there is an automated test for that per endpoint, and whether a new endpoint can ship without one.

4. Where is it hosted, and who can reach it?

For European sellers handling European customers’ messages, the data should be in the EU, and the vendor should be able to say exactly where, and what runs there. Ask whether the database is reachable from the internet at all (it should not be), and whether administrative access is by key, with logging, or by password.

5. What leaves the system, and to whom?

Translation, summaries, drafting: anything AI-assisted means customer text goes to a model provider. Ask which providers, whether they retain prompts, and whether you can switch the feature off and keep everything in-house. Ask the same about email sending, error tracking and analytics. The honest answer is a list, not “we take privacy seriously”.

6. Who did what?

Every action that matters (a refund, a change of settings, a new member, an export, a deleted workspace) should be in an audit log with the actor, the time and the target. Not for compliance theatre; for the day the operator asks who refunded order 4471 and why.

7. Can I take my data out, and can I make it go away?

Export in a machine-readable format, on demand, without a support ticket. Deletion that actually deletes: a grace period is reasonable, a permanent “soft delete” that keeps everything forever is not. Both should be in the product, not in an email to the vendor.

8. What breaks if the tool goes down, and how would anyone know?

Support tools sit between you and a 24-hour clock. If sync stops, messages silently pile up on the marketplace while the inbox looks calm. Ask whether there is a health check that fails loudly when the background worker stops, when a connection keeps failing, or when outbound mail is stuck, and who is watching it.

9. Backups, and has a restore ever been done?

Nightly backups are table stakes. The question that separates a real answer from a slide is: when did you last restore one, and how long did it take? A backup that has never been restored is a hope.

10. What is the minimum access the tool actually needs?

A good tool asks for the narrowest key that does the job and tells you what it does with it. Read-only where reading is enough (a shipping platform key used only for tracking should not need label creation). Where write access is unavoidable, as with Mirakl refunds, the tool should require a human confirmation for every write that moves money, re-verify the state immediately before acting, and log the result. “We only use it to…” is a claim; a confirmation step and a log are evidence.

Two things you should do on your side

Give each tool its own key. Marketplaces let you create several API keys, or several API users. One per tool means one can be revoked without breaking the others, and the marketplace’s own logs tell you which tool did what.

Rotate when people leave. If a departing colleague ever saw a key, rotate it. Tools that store keys properly make this a two-minute job: paste the new key, probe, done.

The uncomfortable summary

A helpdesk with your marketplace keys can refund every order you have. Most vendors will never touch that power, but “will never” is a promise and the questions above are checks. Prefer the vendor who can answer all ten without looking anything up; that is the vendor who has thought about the day it goes wrong.

We publish our own answers on the security page. Hold us to them.