Data sources, processors and AI disclosure
This page exists so that a selling partner, or an Amazon reviewer, can see without asking us: where our numbers come from, who else can touch them, exactly what a language model ever receives, and how to switch that off. It is written to satisfy sections 2.2, 2.4, 2.10, 4.7 and 4.9 of the Amazon Selling Partner Acceptable Use Policy.
Last updated: 14 August 2026 · Questions: support@secew.com
1. Where Amazon information comes from
All Amazon information in GlassBox comes from Amazon, through interfaces the selling partner has authorised, or from files the selling partner exports from Seller Central and uploads themselves. There is no other route in.
Where each interface stands today. The Amazon Advertising API row below is live: it is authorised and in daily use. The Selling Partner API row describes access we have applied for and that is still under review — no Selling Partner API credential is stored on our installation, so nothing on that row is running today. Report-file upload works today and needs no API at all. We would rather say this on the page than let the tense of a sentence imply an authorisation we do not yet hold.
| Source | Exactly what is read | What it is used for |
|---|---|---|
| Amazon Selling Partner API access under review; once granted, authorised by the seller and revocable by them at any time |
Sellers API: marketplace participations. Reports API: Search Query Performance; AFN inventory by country; all-listings report. Catalog Items API: attributes, parent-child relationships, sales ranks, images, summaries. Product Fees API: fee estimate for the seller's own ASIN at the seller's own price. Product Pricing API: current offers and Buy Box position for the seller's own ASIN. Finances API: financial events, aggregated per SKU and fee type. |
Everything described on the Features page, grouped there by the role each call needs. |
| Amazon Advertising API separately authorised by the seller; in use today |
Search term, advertised-product and purchased-product reports; campaign, ad group, keyword and negative-keyword structure; bids. | The negative keyword engine, the bid engine, campaign advice, and execution of approved actions. |
| Files the seller uploads | Advertising reports (CSV, XLSX, TSV, English and German), bulk operations workbooks, variation maps, Search Query Performance exports, cost-of-goods tables. | The same analysis, for sellers who have not connected an API, or for historical periods the APIs no longer serve. |
| The seller's own business systems optional, seller-configured |
The seller may connect their own inventory or ERP system, or an e-commerce store they operate, using their own credentials, to supply supplier profiles, purchase-order history, landed cost and stock counts. | Lead-time estimation from the seller's own purchase history, landed cost, and stock positions that Amazon does not hold. Two honest notes on this row. First, supplier master data and purchase-order history are the seller's own supply-chain records — they originate with the seller's suppliers and freight forwarders, and no Amazon interface exposes them. Second, an ERP that the seller has themselves connected to their own Amazon account can mirror Amazon fields back to us — FBA quantities, listing status, recent unit sales, returns, fee averages. Those fields are Amazon information even though they arrive second-hand, and we are moving them to their Amazon sources: FBA quantities to the AFN inventory report, fees and returns to the Finances API. After that migration this connection carries supplier and purchase-order data only. |
2. Sources we do not use
GlassBox does not obtain Amazon information from any third-party data vendor. We do not buy, subscribe to, resell, embed or promote any external service that vends data scraped or derived from Amazon's websites — no rank trackers, no price-history vendors, no market-share estimators. Where the product needs a catalogue attribute, a sales rank, a fee or a competitive offer, it asks Amazon for it through the Selling Partner API. Where the product needs history that Amazon's APIs do not serve retrospectively, it builds that history from the selling partner's own daily snapshots taken while they are our customer, and says so on the figure.
GlassBox does not read Amazon's retail pages. Nor do we use or offer browser extensions that read Seller Central on the seller's behalf, shared or purchased seller credentials, or datasets assembled from other sellers' accounts.
What changed, and when. We are stating this plainly rather than presenting the current state as if it had always been true.
- Until August 2026 the application could read a third-party market-data service for sales rank, price history and fee figures. That service returned Amazon information from outside Amazon. We accepted the objection instead of arguing it: the integration is now behind a single installation-wide switch set to Amazon sources only, and the fields it used to supply are read from the Selling Partner API's Catalog, Product Fees and Product Pricing endpoints, or reported as not yet measurable while our own daily snapshots accumulate.
- Over the same period the application could also request a small number of Amazon retail
product pages, to read the badges and delivery text a shopper sees. Two things about how
that was written deserve naming rather than glossing over, because they are the part we are
least comfortable with: it sent a desktop browser user-agent and browser-like headers, so
the request would not look like software, and it carried a detector for Amazon's anti-bot
page. On 13 August 2026 we stopped it at the source. The fetching module now has its own
gate, checked once at its entry point — before any HTTP client is created and before any
cache is read — and again immediately before the socket call, so a future caller cannot
bypass it silently. The setting behind that gate defaults to off, cannot be turned on
through the ordinary settings form, and is overridden anyway by the installation-wide
Amazon sources only mode this installation runs in. The browser impersonation is
deleted: the client now identifies itself as
GlassBoxAds/1.0. The anti-bot detector is deleted outright and replaced by a positive test — a page counts as read only if it contains the product-title element. The 59 cached pages were deleted on 12 August 2026, with the deletion recorded in the audit log. - The signals that path used to produce now come from Amazon: list price and badges from Catalog Items, delivery estimates from Product Pricing. Where Amazon does not expose a field, the product reports it as unavailable, with the reason in words — never as "no badge" and never as a zero.
- Category best-seller discovery went with it. Competitor tracking, where a seller uses it at all, works only from ASINs that seller enters themselves.
3. Artificial intelligence: where it is used, what it receives, how to turn it off
Amazon's Acceptable Use Policy, section 2.4, requires providers to be explicit about the use of models such as artificial intelligence, their accuracy, and data freshness. Here is that, in full.
3.1 The rule that governs everything below
A model never writes to Amazon, and never decides anything. Every change that reaches a seller's Amazon account has travelled: proposal → deterministic validators → explicit human approval → execution by code → entry in the audit log. A model can appear only in the first step, and only as one input among several. This is structural, not a policy promise: the code that writes to Amazon takes its input from approved rows in the approval queue, never from a model's response, and a model holds no Amazon credential. Approval is manual by default: per-action automatic approval exists, ships disabled in every category, and is refused outright whenever the report underneath it is stale.
3.2 Every place a model is used
There are four. All are optional, none of them is reachable unless a model provider key has been configured, and on our own installation no such key is configured today — so nothing is being sent at all as this page is written. The provider, when one is used, is Anthropic PBC (United States), acting as our processor under their commercial terms. No other model provider receives anything.
Two of the four send real figures. We are listing them the way they actually behave rather than describing the strictest one and letting you assume the rest match it.
| Feature | What is sent | What is deliberately not sent | Control, and what happens without the model |
|---|---|---|---|
| Search term relevance (negation engine, layer 0) |
Each search term string together with the ad group name and campaign name it was seen in, exactly as they are written in the seller's own advertising account, plus one context line: the brand words the seller typed into our settings, the marketplace country code, and up to twenty of their ad group names. Read that literally: sellers routinely put their own ASINs into campaign and ad group names, and where they have, those ASINs are in the payload. In the account this software was built against, 195 of the 205 campaign/ad-group name pairs in our daily advertising table contained one when we last counted, on 14 August 2026. No performance figure travels with them. | No sales, no orders, no spend, no click counts, no conversion rates, no prices, no fees, no per-ASIN performance, no financial data, no buyer data, no personal data. | Named setting, on its own. Off: a deterministic relevance heuristic classifies every term. That heuristic runs in both modes and co-signs the model's answer; brand protection is deterministic and a model can never override it. |
| Daily briefing narrative | The briefing our own code has already computed, with its real numbers in it: the length of the reporting window, total advertising spend, total advertising-attributed sales, ACoS, wasted spend, and up to five proposed actions with their search terms and expected monthly impact. The model is instructed to keep every number exactly as given and to rewrite the prose only. | No order-level records, no buyer data, no personal data, no other seller's data. But be clear about the limit of that instruction: it is an instruction, not a guarantee. The figures above do leave our systems when this feature is on, and the returned text is not re-checked number by number — only a truncated or failed response is discarded. | Named setting, on its own. Off: the deterministic briefing is displayed as our code wrote it, unchanged. |
| Executive summary rewriting (the account brief) |
A masked template. Before the call our code replaces every number, every ISO date and
every ASIN with markers of the form {{A}}, {{B}}. The model
receives prose with gaps and no figure or identifier at all. |
Nothing beyond the masked prose. Our code substitutes the real values back afterwards; if a single marker was lost, altered or invented, the model's answer is discarded and the deterministic text is used instead. | Governed by the provider key: with no key configured it does not run. Without it, the deterministic brief is shown. |
| Pattern hypotheses | Short sentences that our deterministic pattern detection has already produced from this seller's own catalogue. They can contain the seller's own ASINs, their own product attributes such as colour and size, click counts, conversion rates, and the percentage share of their own advertising spend against their share of sales per product family. | No absolute money figures, no buyer data, no personal data, no other seller's data. If deterministic detection found no pattern, the model is not called at all — we will not manufacture a "pattern" with nothing behind it. | Governed by the provider key. Without it, only the deterministic patterns are shown. Everything the model returns carries a visible "hypothesis, not a measurement" badge and is never used in any calculation. |
3.3 Why any of it is sent at all
Each of the four exists solely to produce the output the authorising selling partner asked for, for their own account: a cleaner set of negative keyword candidates, a readable briefing about their own account, a readable account summary, and additional hypotheses about their own catalogue. Two of those are language judgements — deciding that the search term "dog collar" is irrelevant to a telescopic pole is not arithmetic — and two are readability. Nothing is sent for our benefit, for another customer's benefit, or for any purpose the seller did not request. Anthropic acts as a processor: they process only on our documented instructions, and under their commercial terms API inputs and outputs are not used to train their models.
3.4 Your controls, stated exactly
- No key, no calls. This is the master control and it is the one in force on our installation today. Every one of the four paths first asks for a configured provider key; with the field empty, none of them executes and nothing leaves for a model provider.
- Two named settings, and what they actually cover. One setting disables the search-term classification path; a second disables the daily briefing narrative. They are independent of each other. They do not govern the executive summary or the pattern hypotheses — those two are governed by the presence of the key. If you want a guarantee that nothing at all is sent, remove the key; the two settings alone do not give you that.
- Bring your own key. Enter your own Anthropic API key and the requests run under your own agreement with Anthropic rather than ours, and we are not in that data path. Your key is stored encrypted and is used only for your account.
- Nothing degrades into a guess. Any error, timeout, truncated response or missing key falls back to the deterministic result. The product never depends on the model being available.
- See the labels. Anything a model produced is labelled in the interface. Hypotheses carry a visible badge saying they are hypotheses and not measurements.
3.5 Accuracy and data freshness
- Every figure carries the method that produced it — counted, Bayesian, frequentist, heuristic, or taken from an external report — and a combined figure inherits the weakest of its inputs. The Features page explains the five kinds.
- Every source carries the date of the data behind it. Daily series older than three days are marked stale in the interface, and the engines that depend on them say so on the recommendation. A source with no known date is shown as unknown, never as today.
- Predictions are stored when made and scored when their horizon matures. The resulting error is displayed in the application, with the number of predictions it rests on.
- Below the minimum volume thresholds the application abstains and explains why, rather than producing a recommendation with no evidence.
- Integrity and validation checks, as section 2.10 requires. Nothing a model produced is trusted on its own: the executive summary is discarded whole if a single restored marker fails to match, a truncated or failed response is discarded and the deterministic text used instead, a relevance label for a term that was never sent is dropped, and the deterministic brand and whitelist rules over-rule any label. Independently of models, every action passes a deterministic validator immediately before export or execution — whitelist, brand terms, recent conversions, stock position, unit margin, batch-size cap, bid-movement cap — and an action whose underlying report is stale is held back before it can be exported or executed; releasing it takes a deliberate override on that single request, and automatic approval on stale data is off by default.
- The deterministic engines are covered by an automated suite of over six thousand tests, including end-to-end runs from ingest through audit, approval, export and de-duplication.
4. Processors that can receive data
This is the complete list. If it changes, this page changes first, and customers are notified before the change takes effect.
| Processor | Purpose | Data categories | Location | Optional? |
|---|---|---|---|---|
| IONOS SE the virtual server the application runs on |
Hosting of the application and its databases. | All customer data held by the service. | Germany (European Union) | No — required to run the service. |
| Anthropic PBC | The four optional model-assisted features in section 3. | Exactly the fields listed in the table in section 3.2, and nothing else. No provider key is configured on our installation today, so this processor currently receives nothing. | United States | Yes — remove the key and no path runs; or supply your own key and contract directly with them. |
| Paddle the payment provider the application is integrated with, acting as merchant of record |
Subscription billing, invoicing and VAT handling. | Billing name, billing email, billing address, VAT number, payment status. No Amazon information. Paid plans are not yet switched on and no billing data has left the application to date; this row describes what will happen when they are. | United Kingdom | No, for paid plans. Not used at all while you work from your own report files, which is free. |
| None engaged transactional email |
Address verification, password reset and service notices would go through an email provider. | Email address only; never Amazon information. We hold no account with an email provider today, and the application is built so that with none configured it sends no mail at all. When we engage one, this page changes before it does. | — | — |
| Telegram Messenger | Delivery of alerts and briefings to a chat the seller chooses. | Only the content of the alerts the seller has enabled, which can contain their own account figures. | Operated by Telegram | Yes — off by default. It only works if the seller enters their own bot token and chat identifier, and it is their own instruction to send there. |
| An assistant provider you choose optional read-only connector |
The application can expose a read-only connector so that an administrator can attach their own AI assistant to GlassBox. It offers a fixed set of read-only tools — account health, advertising waste, weekly priorities, profit summary, inventory status, keyword and product performance, lead times — and cannot write anything, to GlassBox or to Amazon. | Whatever those read-only tools return, to whichever assistant provider the administrator connected. That is their disclosure to make, not a transfer we initiate. | Wherever that provider operates | Yes — off by default, protected by a high-entropy rotating token, and switched on only by an administrator. It is not enabled on our installation. |
Before engaging any processor we assess its security posture and require standards at least as strict as our own, as Amazon's Acceptable Use Policy section 4.7 requires. Contracts include confidentiality, purpose limitation, and a prohibition on using the data for the processor's own purposes. Where personal data leaves the European Economic Area, transfers are covered by the European Commission's standard contractual clauses.
Amazon information is disclosed to a processor only where doing so is required to perform the activity the authorising selling partner asked for, on their own account. It is never disclosed to another customer of ours, to an affiliate, to an advertiser, to a data broker, or to anyone else.
5. Isolation, encryption and access
- One database per customer. Each selling account's data lives in its own database — in our deployment, its own database file — not in shared tables filtered by an account column. A query cannot accidentally cross the boundary, because there is no shared table to cross.
- Credentials encrypted at rest. API keys, refresh tokens and any key a seller supplies are encrypted before they are stored. The master key is supplied through the deployment environment, is never stored in the database, and is not captured by database backups — a copy of the database on its own decrypts nothing. Credentials are never written to logs and never displayed after entry.
- Transport encryption. All traffic between the browser and the service, and between the service and Amazon, uses TLS.
- Least privilege inside Secew. Access to a customer's data is granted only to staff who need it for a specific support task, is logged, and is withdrawn when the task ends.
- Everything that happens is logged. Proposals, approvals, rejections, whitelist entries, exports and executions are recorded with timestamp, actor and evidence. The log is visible to the customer.
- Revocation is yours. You can withdraw the application's authorisation in Seller Central or in the Amazon Advertising console at any time, without telling us. When you do, the application stops being able to read or write anything.
6. Retention and deletion
- Amazon reports and derived analysis are retained while your subscription is active, up to the history limit of your plan.
- After a subscription ends, data is retained for 30 days so you can return or export, then deleted.
- You can request deletion at any time, in writing, to support@secew.com. We complete it within 30 days and confirm in writing when it is done.
- Deleting an account deletes its database, including reports, recommendations, audit log and stored credentials. Daily backups rotate automatically. Historical recovery archives require a separate review and removal or rewriting of every copy that contains the account, including cloud copies, before deletion is confirmed within 30 days. Credentials stay encrypted inside a backup exactly as they are inside the live database; the master key is not in either.
- We retain invoices and the records tax law requires us to keep. Those contain billing details, not Amazon information.
7. What we never do with Amazon information
- We never aggregate data across our customers' businesses to produce or sell anything to anyone, including to other customers.
- We never publish, promote or share insights about Amazon's business, and we do not use such insights for our own business purposes.
- We never sell, rent, license or trade any customer's data.
- We never use one customer's data to produce a recommendation for another customer.
- We never request or accept a seller's Seller Central username or password. Authorisation happens through Amazon's own flows.
- We never request access to data we do not need. GlassBox requests no role whose purpose is access to buyer personal data, requests no restricted data token, calls no Orders API, and holds no personally identifiable information about Amazon customers.
- We never use customer data to train a model, and our processor is instructed not to.
- We never market to Amazon customers, and we hold no means of doing so.
Something here unclear, or contradicted by what you see in the product? Write to support@secew.com and we will correct the page or the product, whichever is wrong.