Twelve things Firesell will never do to your Amazon account.

The whole list, before the detail

Every line links to the mechanism that enforces it. Nothing below is a promise about intentions: each entry says what kind of guarantee it is, and 6 of the twelve are only decisions a person could reverse.

1. 01Ask for your Amazon password
2. 02Ask Amazon for your buyers’ personal information
3. 03Log into Seller Central as you
4. 04Show anyone a stored credential
5. 05Let one organization’s credential touch another’s account
6. 06Put credential material in a log or a workflow history
7. 07Submit a bulk or destructive change you have not read
8. 08Execute an approved plan that no longer matches reality
9. 09Run something catalogue-wide while you are not looking
10. 10Let a model rewrite your listing content on its own
11. 11Show you a number we do not actually have
12. 12Leave a usable credential behind after you disconnect

• ArchitectureA permission or a key that does not exist. No code we could write would do this, and a named check proves the permission is absent.
• Verified by testA check that must pass before any live seller credential is accepted. It is a gate on shipping, not a report from production.
• PolicyA decision, written down, that a person could reverse. Stated as such rather than dressed up as a guarantee.

None of this has yet run against a live seller credential. Where the refusals stop says what that means, and what else is missing.

First, what we will never ask you for

The shortest route to a credential you cannot lose is never to collect it. Three things this product does not want, has no use for, and has no field to receive.

1. 01

   Policy

   We will never ask for your Amazon account password.

   Nor an AWS access key, an AWS secret key, or an IAM role ARN. None of the four is needed for any call Firesell makes, and none is collected. A connection takes seller-owned Selling Partner API credential material and nothing else — which is why the connection screen is short and slightly disappointing.

   Fails if a new field appeared on the connection form — in front of you, before you typed anything into it.

2. 02

   Policy

   We will never ask Amazon for your buyers’ personal information.

   Firesell does not request the Selling Partner API roles that carry buyer personal data, so none is ingested and none is stored. Amazon’s data protection policy caps how long that information may be retained after delivery, and the cheapest way to meet a retention limit is to never hold the data.

   The limit on this one This is a scoping decision, not a law of the system. Any future order feature that genuinely needed buyer data would have to re-open it, which means requesting a new role from Amazon and re-authorising the connection.

   Fails if Amazon granted a role Firesell has not applied for, and you approved the wider access yourself.

3. 03

   Policy

   We will never log into Seller Central as you.

   No browser automation, no scraping, no headless session wearing your login — ever, as a standing constraint rather than a current preference. Every call goes through a registered Selling Partner API application, over the documented interface, subject to the throttles Amazon publishes.

   This costs real capability. Things Amazon exposes only in the Seller Central interface are things Firesell cannot do, and it will say so rather than reach around the API to get them.

   Fails if Firesell ever drove a browser session on your behalf — which would not be a configuration change but a different product, built on the exact practice that gets tools banned.

Then, what we could not do even if we decided to

These three are not restraint. They are permissions that were never granted to the part of the system serving this page — and a promise that stops depending on us is worth more than one that does not.

1. 04

   Architecture

   We will never show anyone a stored credential — including you.

   There is no reveal-credential screen for any role: not for support, not for your own organization’s admin, not for you. That is not a missing feature that could be added in a sprint. The web tier holds kms:Encrypt and kms:GenerateDataKey and never kms:Decrypt, so it cannot read a credential it sealed itself, and no screen it serves could display one. Only the worker that makes the Amazon call decrypts, at the moment of the call.

   The same split is why there is no “test my saved credential” button in the web application. Verification is work the worker does, because the web tier is the part exposed to the internet and it has been kept deliberately useless for reading secrets.

   Fails if AWS granted the web tier a decryption permission its role does not have. A negative test asserts that the attempt is refused, and it must pass before any live credential is accepted.

2. 05

   Architecture

   We will never let one organization’s credential touch another’s account.

   Each sealed credential is bound by encryption context to the organization, the connection and the credential version it belongs to. Decryption with a mismatched context fails, so a ciphertext row lifted into another tenant is not a risk to be caught by a check — it is an unusable blob. Underneath that, every tenant table carries row-level security, and composite (organization_id, id) foreign keys mean a child row cannot reference another tenant’s parent at all.

   Fails if one of the named pre-launch checks started passing where it is supposed to fail: copy a ciphertext row between organizations, attempt to decrypt it, and watch it refuse.

3. 06

   Verified by test

   We will never put credential material in a log or a workflow history.

   Background work runs on a third party’s durable orchestration service, which permanently stores workflow arguments, results, failures, heartbeats and search attributes. Credential material is excluded from all of them by a redacting failure converter and a payload codec that are build-time requirements rather than conventions — and sealed ciphertext is treated exactly like plaintext for that purpose.

   The same rule covers application logs, traces, error bodies and idempotency receipts. The check is run against the ugliest case deliberately: submit a credential, make the submission fail, then read everything the failure wrote.

   Fails if the redaction check failed — and it runs before a live credential is accepted, rather than after an incident.

Then, what we will never do to your catalogue

The complaint that ends relationships in this category is not slowness. It is a tool doing something large, irreversible and unrequested — and then being unable to say exactly what it sent.

1. 07

   Architecture

   We will never submit a bulk or destructive change you have not read.

   Every bulk or destructive write to Amazon is two phases. First a change plan is written down and shown to you: the difference per SKU, and the number of listings it affects. Nothing is submitted until you approve that specific plan.

   Approval is bound cryptographically to the person who gave it and to a hash of the plan’s contents, and the worker re-verifies that binding before it writes anything. Approved is never a bare boolean on a row — a flag that can be flipped by a bug is not consent, and this is the one rule the rest of the write path is built around.

   Fails if a worker executed a plan whose content hash does not match what you approved, which is the first condition it checks.

2. 08

   Policy

   We will never execute an approved plan that no longer matches reality.

   The subtler version of the same failure: you approve a change at nine in the morning, something moves underneath it, and the tool applies your stale decision at two in the afternoon. A plan will carry an expiry, and a plan invalidated by drift in the underlying state will not execute; it is re-planned and re-shown instead. Reconnecting an account does not revive an old approval either; an approval belongs to a plan and a moment, not to a connection.

   The limit on this one Unlike 07, this one rests on no invariant of its own. Plan expiry and drift invalidation are a scheduled part of the change-plan system and are not built yet, so it is graded policy and not architecture.

   Fails if an expired or drifted plan passed the state check it is designed to fail, or that check shipped weaker than it is written here.

3. 09

   Policy

   We will never run something catalogue-wide while you are not looking.

   Automation will be an allowlist you configure, defaulting to suggest-only: Firesell tells you what it would do, and waits. Nothing runs unattended across a catalogue because a default said it could.

   The limit on this one This is a design commitment in the planning record, not a permission that has been removed, and the automation surface is not built. It is listed as policy for that reason, and it is worth judging by whether that surface, when it ships, actually defaults to suggesting.

   Fails if a default changed, quietly, in a release. That is exactly the move that makes this grade policy and not architecture.

4. 10

   Policy

   We will never let a model rewrite your listing content on its own.

   Firesell ships no AI feature, and agent interfaces are blocked outright until the primary text of Amazon’s Business Solutions Agreement has been read first-hand rather than summarised. If anything of that kind is built, a suggest-versus-approve permission model is a precondition for it, not a setting inside it.

   Sellers in this category are already watching automated rewrites arrive on their own listings from elsewhere. A tool that adds a second source of unrequested edits is not helping.

   Fails if an AI surface shipped with an apply-without-review path. There is no such surface to inspect yet, which is precisely why this is policy.

And last, what we will never do to your data, or after you leave

Two refusals about the moments a tool is least observed: when it does not know something, and when you have stopped paying attention to it.

1. 11

   Architecture

   We will never show you a number we do not actually have.

   Every figure Firesell displays is a claim about Amazon’s systems at a past instant, so freshness is carried by the value itself rather than left to a timestamp you have to do arithmetic on. A refresh that failed renders as the previous value, marked stale, with the reason and a retry. A value never successfully fetched renders as Not set or Unavailable — never as zero, because zero is a number an operator acts on.

   The same honesty applies to failures. A timeout means the outcome is unknown and is reported as unknown; it is not relabelled as invalid credentials, and a missing permission is not reported as a revocation. Those are different sentences with different next actions, and collapsing them is how an operator ends up re-submitting something that already went through.

   Fails if a failure category were invented outside the closed set the interface and the backend share — which is a type error rather than a judgement call.

2. 12

   Verified by test

   We will never leave a usable credential behind after you disconnect.

   Disconnecting stops use immediately, before any cleanup begins, so there is no window in which work already in flight can still obtain credentials. Then every active and candidate credential version for that connection is deleted, retryably and observably — a cleanup that fails silently is a cleanup that did not happen.

   The case most tools get wrong is the one after that: a database backup restored months later, containing a connection you disconnected. That is a named pre-launch check, and the required result is that the connection comes back disconnected and unusable.

   Fails if the restore rehearsal showed a disconnected connection waking up with working access.

Where the refusals stop

A list like the one above is cheap to write and expensive to keep, and it is cheapest of all for a company with no customers yet. So here is the other side of it, in the same place rather than in a policy nobody opens. None of this is unusual. Stating it is.

No store protects a secret from a workload authorised to retrieve it.

The worker that calls Amazon on your behalf can read your credential at the moment of the call — that is what makes it useful. The design bounds how far a compromise reaches; it does not eliminate the authorised-consumer case, and a page claiming otherwise would be lying.

Firesell is one maintainer.

There is no security team, no multi-factor-authentication policy, no quarterly access review and no background-check process, because there is nobody to run them. The guarantees above are deliberately architectural instead of procedural for exactly that reason: a permission that was never granted does not depend on anyone remembering.

No SOC 2, no ISO 27001, no penetration test, no external audit.

None has happened, so none is claimed. If you require one before connecting an account, Firesell is not ready for you yet — which is a straight answer rather than a sales objection to handle.

No uptime figure and no availability guarantee.

Nothing is measured yet and nothing is contractual. A number here would be decoration.

No customers, so no testimonials, no logos and no counts.

You will not find a wall of them on this site, because there is nothing to put on it. Every claim above is written so it can be checked against a mechanism instead of against a stranger’s quote.

The checks named above are gates, not production reports.

No live seller credential has been accepted yet. Each verification referenced on this page must pass before one is, which is a commitment about sequence — and the one thing here you cannot verify from outside.

The same accounting, at more length, is on the security page.

Now the other half: what Firesell is for

Shorter than the refusals, and deliberately so. This is the whole of what the planning record supports; nothing has been added because a section like this usually has more in it. What is built, what is scheduled and what is merely captured are three different things, and the next section is where they are separated.

Listing, inventory and pricing operations

One place for the operations Amazon makes you do one at a time, across the marketplaces a connection covers.

One connected seller account, many marketplaces

Connect an Amazon selling account and work across its marketplaces in one place. Connections are scoped to a Selling Partner API region, and an organization can hold more than one.

Change plans before anything is submitted

Every bulk or destructive change is planned and shown before it is submitted, and approved explicitly. Refusals 07 and 08 are the same mechanism seen from the other side.

Credentials this web tier cannot read

Credentials are envelope-encrypted with a managed key, and the tier serving this page cannot decrypt them. Credential material never appears in logs or workflow history.

Organizations, roles and invitations

Team access is organization-scoped, with roles and invitations, so an agency or a staffed business is not sharing one Amazon login.

Data held in the United States

Application data and encrypted credential ciphertext are held with named subprocessors in the United States. The list is published as part of the privacy policy, not given out as a support answer.

What it does not do yet

The same disclosure you would otherwise find out after connecting, which is the wrong time to find it out.

Amazon only, until v1.

No second sales channel, and no claim of channel-neutrality before one exists. If you need a second marketplace today, this is not the tool.

Connecting is a manual pilot bridge.

You supply your own Selling Partner API credential material. There is no one-click Amazon authorisation: a public Firesell application is planned and unscheduled, and until it exists the manual path is what there is. Connection handling is built so the public application arrives as a new credential version rather than a migration you have to survive.

Pre-launch.

Firesell has not yet accepted a live seller credential from anyone. If you want to be among the first, email us — that is a conversation, not a signup queue with a number on it.

No pricing has been set.

There is no pricing page, because there is no price. Inventing tiers to fill the gap would be the first thing on this site you could not check.

Who you would be dealing with

If you are weighing up handing over account access, the least you should get is a name and a mailbox that answers. Firesell is built and operated by Maikhana LLC, which also sells on Amazon — worth knowing before you connect an account, which is why it is here and not in a footnote. Every message reaches a person, and each one gets a reply.