Privacy Policy

Inspekt is a renderer, and showing someone a weapon skin does not require knowing who they are.

Effective 20 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 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, you are responsible for telling your own users about it, 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

We write every call to the embed, Render API or Inventory API as one usage event holding a timestamp, the API key used, the event kind, the start of the billing period it counts toward, 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. We check the origin a request came from when it arrives and do not write it 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. We combine the requesting IP address and browser user-agent string with the customer's key and the item being shown, and hash the result under a secret that exists only in the running service's memory and is discarded when the service restarts. We keep that hash in memory for 24 hours from the last view. We built it this way to give it three properties:

• 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 and does not note whose view it was.

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.

We hold the caller's IP address in memory for a sliding window of roughly 60 seconds, only to enforce a per-IP rate limit that keeps us from hammering Steam. We discard it when the window goes idle, write it to no log, and do not link it 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. The IP 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 key, and each key a rotation replaced with the date it was retired, so a support request about an old key can be answered and its usage records found. We also hold your account or business name, whether it is an individual or an organisation account, your plan, your registered origins, any quota or rate limit set for your account in place of the plan's, the date your billing periods are counted from, the date and version of the terms you accepted, and the account's status, with the reason when it is suspended. An account we set up by hand can also carry a contact address and our own notes about it. This is business data about a customer. None of it is 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 and 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 the account it is signed in to; and
• a CSRF token, used only to confirm that a dashboard action came from the dashboard.

An invitation to an organisation account uses 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.

We deliver sign-in links by email through our mail provider. For a successful send we record 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, we write the link 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. We purge those entries after 30 days.

2.8 Billing

Our payment processor, Stripe, handles payment card and billing details 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. The counting runs on Umami, which we host on our own server. Our Umami instance 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. The origin passes it to that server, with the IP address used for the daily code described below, over an encrypted tunnel between two machines we run.

Umami 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, so the code cannot be traced back to you, cannot be matched to yesterday's and cannot follow you to another site.

Three places have no analytics at all: the embed, because 2.2 promises it talks to nobody but us; the dashboard; and the sign-in link page, whose address carries a single-use token that does not belong in 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 we measure, we host ourselves.
• No retained database of Steam inventories beyond the 5-minute cache in 2.4.
• No password for the dashboard.

4. Why we process it

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

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, and no third party is in that path.
• 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

A purge inside the service enforces the 13-month figure. Thirteen months covers a full year of billing plus the month in progress.

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

7. Security

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

We store sign-in links and session tokens only as hashes, so a copy of our session store does not let anyone sign in as you. We send mail over TLS, and our mail client refuses to authenticate over an unencrypted connection.

We are a small operation and claim no security certifications.

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, and we collect it that way on purpose.

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. 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. They are 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. If the account has a live subscription, the subscription has to be cancelled first, because deleting the record would otherwise leave it 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.