Privacy Policy

Inspekt is a renderer. Showing someone a weapon skin does not require knowing who they are, and this policy describes what that means in practice.

Effective 18 September 2026. Menu Atlas LLC, a Utah limited liability company.

This policy covers how Menu Atlas LLC ("we") handles data in running Inspekt: the embed, the Render API and the Inventory API. It covers both our customers and the visitors who meet the service through a customer's site ("end users"). Terms defined in the Terms of Service carry the same meaning here.

This is not a substitute for your own privacy policy. If you put the embed on your site or call our APIs, telling your own users about it is your job, in your own policy.

1. Scope

This covers the service as we run it. It does not cover your site, your app or your data practices, and it does not cover Steam or Valve, whose own policy governs the inventory and inspect-link data we read from their public services on request.

2. What we collect

2.1 Usage records

Every call to the embed, Render API or Inventory API is written as one usage event holding a timestamp, the API key used, the event kind, whether the response came from cache, whether it was over quota, and a reason code if it was refused.

The API key identifies the customer account, not a person. These records carry no end user identity, no IP address, no device information and no cookie or tracking identifier. The origin a request came from is checked when it arrives and is not written into the record. We use this only to enforce quotas, work out bills, and operate and debug the service.

2.2 The embed

The embed sets no cookies and makes no request to any third-party domain from inside the frame. Its API calls go to our own origin, and its textures, models and other static files come from cdn.inspekt.gg, our own name, served through a content delivery network. Viewing it collects nothing about the viewer beyond the anonymous usage event above and the short-lived value described next.

How we tell a returning viewer from a new one. An embed load counts once per viewer, per item, per 24 hours (Terms 5.6), so we have to recognise a second look. We do that without a cookie and without keeping anything that identifies you: the requesting IP address and browser user-agent string are combined with the customer's key and the item being shown, and the result is hashed under a secret that exists only in the running service's memory and is discarded when it restarts. What is kept is that hash, for 24 hours from the last view, in memory. Three consequences, and they are why it is built this way rather than side effects of it:

• It cannot be reversed to an address or a device, by us or by anyone, because the secret is never written down.
• It cannot be joined across customers. The customer's key is inside the hash, so the same person on two different sites is two unrelated values. This cannot become a record of where anyone has been.
• It never reaches disk. The usage record in 2.1 notes that a view was a repeat. It does not note whose.

2.3 The Render API

A render is produced from the parameters in the request and cached under a hash of those parameters, never under anything identifying the requester. Nothing about who asked is stored with a cached image.

2.4 The Inventory API

This takes a Steam ID, vanity name or profile URL from the caller and looks up that account's public CS2 inventory through Steam. The result is held in server memory for up to 5 minutes, capped at 200 accounts with the oldest evicted first, and is never written to disk. We do not build a database of anyone's inventory.

The caller's IP address is held in memory for a sliding window of roughly 60 seconds, purely to enforce a per-IP rate limit that keeps us from hammering Steam. It is discarded when the window goes idle, is not written to any log, and is not linked to the usage records in 2.1.

2.5 Infrastructure logs

Our hosting and network layer may record connection metadata such as IP addresses, the way any web server does. The application behaviour described above never writes an end user's IP to disk: it is used, in memory, for the rate limit in 2.4 and for the view hash in 2.2, and for nothing else.

2.6 Customer account data

To run your account we hold your API keys, account or business name, plan, registered origins, quota and overage settings, and account status. This is business data about a customer, not data about end users.

An organisation account also holds its member list: for each person who can sign in to it, their email address, their role, when they were invited and when they accepted. An invitation that has not been accepted is the same record with the acceptance missing, and revoking it deletes the record. Removing a member deletes theirs, and ends their sessions on that account. Everyone on the account can see this list; nobody outside it can.

2.7 Dashboard sign-in

There is no password. You enter your email, we send a one-time sign-in link, and following it creates a signed-in browser session. This stores your email address against your account for as long as the account exists; the sign-in link as a hash of its token, never the token itself, with the requesting IP and a timestamp; the session as a hash of its token with a truncated user-agent string, and which account it is signed in to; and a CSRF token used only to confirm a dashboard action came from the dashboard.

An invitation to an organisation account is the same mechanism: a one-time link, held as a hash, which accepts the invitation and signs the invitee in. It carries the name of the account that sent it, so that the person receiving it can tell what they are being asked to join.

Sign-in links are delivered by email through our mail provider. A successful send is recorded as the fact that it happened, with the recipient, time and message id, and without the link, so a working sign-in leaves no usable copy of its own token on our servers. If a send fails, the link is written to an operational log so we can pass it on by hand, because at that point it is the only way you can get in. Those entries are purged after 30 days.

2.8 Billing

Payment card and billing details are handled by our payment processor, Stripe, under its own privacy policy. We never store full card numbers. We hold the identifiers Stripe gives us for your customer and subscription, plus your plan and billing status.

2.9 Site analytics

We count visits to our own public pages — the studio, the documentation, pricing and these legal documents — so we can tell which of them are worth keeping. This runs on Umami, which we host ourselves on our own server. It is not a third-party analytics service, and nothing is shared with an advertising network. Your browser sends each page view to our public origin, which passes it, with the IP address used for the daily code described below, to that server over an encrypted tunnel between two machines we run.

It sets no cookies. For each page view it records the page address, the referring address if you arrived from a link, your approximate country, and coarse device facts such as browser, operating system, language and screen size. It does not store your IP address. To tell a repeat page view apart from a new visitor it derives a short code from your IP address and browser using a secret that changes every day, which means the code cannot be traced back to you, cannot be matched to yesterday's, and cannot follow you to another site.

Three places deliberately have no analytics at all: the embed, because 2.2 promises it talks to nobody but us and that promise is the point of it; the dashboard; and the sign-in link page, whose address carries a single-use token that has no business being written into an analytics record.

3. What we do not do

• No advertising trackers or pixels anywhere, and nothing whatsoever inside the embed.
• We do not sell personal data.
• No tracking cookies. Our own analytics sets no cookie of any kind, and the embed sets none.
• No device fingerprinting, and no identifier that follows anyone between sites or from one day to the next. The daily code described in 2.9 is the only thing of that shape we have, and it is designed not to survive the day.
• No third-party analytics service. What little we measure, we host ourselves.
• No retained database of Steam inventories beyond the 5-minute cache in 2.4.
• No password for the dashboard, so no password to lose.

4. Why we process it

To enforce quotas and calculate bills; to run, secure and debug the service; to prevent abuse, which is what the per-IP limit in 2.4 is for, and it exists as much to protect Steam from us as us from anyone; to sign you in to your own dashboard; and to meet legal obligations.

5. Who we share with

• Steam and Valve. An inventory lookup or inspect-link request necessarily means we ask Steam's public service on the caller's behalf.
• Our mail provider, which carries dashboard sign-in emails and therefore sees the recipient address.
• Stripe, our payment processor, for billing.
• Hosting and network providers, as far as running the service requires.
• No analytics provider. The measurement described in 2.9 runs on our own hardware, so there is no third party in that path to name here.
• Law enforcement or others, where the law or legal process requires it.

We do not sell customer or end user data to anyone for their own marketing.

6. How long we keep it

The 13-month figure is enforced by a purge inside the service, not by a note in a calendar. Thirteen months covers a full year of billing plus the month in progress.

We keep an encrypted off-site backup so that a hardware failure is not the end of your account. It is taken nightly and it holds the account and usage records described above. Backups are overwritten on their own schedule, which is why a deletion can take up to 90 days to reach every copy even though it is immediate everywhere the service reads.

7. Security

Access to usage data and customer account data is limited to people who need it to run the service. The public API surface is protected by the origin allowlist and quota checks described in the Terms. Administrative write access to our own systems is separately controlled and is never granted by a customer API key.

Sign-in links and session tokens are stored only as hashes, so a copy of our session store does not let anyone sign in as you. Mail is sent over TLS, and our mail client refuses to authenticate over an unencrypted connection rather than fall back to one.

We claim no security certifications. We are a small operation and would rather say so.

8. Your rights, and how to reach us

If you are an end user with a question about data collected through a site you visited, ask that site first. We generally cannot identify you from the anonymous usage data in 2.1, which is the point of collecting it that way.

For data we hold ourselves, write to hello@inspekt.gg. You can ask for a copy of the account data we hold about you, ask us to correct it, or ask us to delete your account and the data tied to it, subject to what we must keep for legal and billing reasons. We will respond within 30 days.

You can also delete the account yourself, from the dashboard, without writing to us at all. That removes the account record, its API keys and its sign-in sessions immediately from the live service, and from the encrypted backups within 90 days. The usage records described in section 2.1 remain for the 13 months stated in the retention table, no longer tied to you or to your address, because the account record was the only thing linking a key to a person. If you have ever paid us, we keep the customer identifier our payment processor uses, so that invoices can still be found for tax purposes. An account with a live subscription has to be cancelled first, since deleting the record would otherwise leave the subscription running with no way to stop it.

Depending on where you live you may have further rights, including under the GDPR or the CCPA. Write to the same address and we will handle the request under the law that applies to you. We do not sell or share personal information as those laws define it.

9. Children

The service is not aimed at children and we do not knowingly collect personal information from them. A customer whose own product carries age-verification obligations is responsible for meeting them, under Acceptable Use section 3.

10. Where data lives

We are based in the United States and process the data described here on infrastructure in the United States. If you use the service from outside the US, you are sending data here.

11. Changes

We update this policy the same way we update the Terms, under Terms section 16.

12. Contact

Menu Atlas LLC
c/o Northwest Registered Agent LLC
7533 S Center View Ct Ste N
West Jordan, UT 84084, USA

By email: hello@inspekt.gg

See also the Terms of Service, Acceptable Use Policy, Service Level Agreement and Refunds and Cancellation Policy, and the change history.