Privacy Policy

What data Inspekt collects, why we use it, how long we keep it and who we share it with.

Effective 20 October 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, the Inventory API, the cinematic clips and saved share links in our studio and the Inspekt Lens browser extension. 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.

You need your own privacy policy. If you put the embed on your site or call our APIs, you are responsible for telling your users about it in your own policy.

1. Scope

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

2. Data we collect

2.1 Usage records

We record 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.

Usage records identify the customer account only. They carry no end user identity, no IP address, no device information and no cookie or tracking identifier. We check the origin of each request when it arrives and do not write it into the record. We use these records only to enforce quotas, answer billing questions, and operate and debug the service.

Daily count per visitor address. Each key limits how much any one visitor address may use it in a day, so that a key copied from a customer's page cannot spend that customer's quota. To count this, we store, separately from the usage events above, a row holding the UTC day, the customer's key, the kind of request, a count, and a hash of the requesting IP address made with a secret key. The address itself is not stored, the hash cannot be turned back into an address without that secret, and the row holds nothing else about the visitor. We delete these rows automatically after 3 days. A customer can raise, lower or switch off the limit in their dashboard; while it is off, we store no row.

Saving a share link and loading a long share link (2.13) are counted the same way.

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.

Recognising a returning viewer. An embed load counts once per viewer, per item, per 24 hours (Terms 5.6), so we need to recognise a repeat view. We do this 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 shown, and hash the result with a secret that exists only in memory. We keep the hash in memory for 24 hours from the last view. A planned restart of the service, such as an update, carries the secret and the hashes over in memory, so a view within its 24 hours still counts once. A reboot of the server discards both. As a result:

• It cannot be reversed to an address or a device, by us or by anyone, because the secret is never written to disk.
• It cannot be joined across customers. The customer's key is inside the hash, so the same person on two different sites produces two unrelated values.
• 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 made from the parameters in the request and cached under a hash of those parameters. Nothing about the requester 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 on lookups sent to 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, as any web server does. The service itself never writes an end user's IP address to disk. It uses the address in memory for the view hash in 2.2, the rate limit in 2.4, the daily count in 2.1, which keeps only a hash, the analytics code in 2.9, the render allowance in 2.10, which also keeps only a hash, and the request count in 2.10, and for nothing else. For an IPv6 address, each of these uses only its first 64 bits, the network one home or one server is given, in place of the full address.

2.6 Customer account data

To run your account we hold your API key, and each key replaced by a rotation with the date it was retired, so that questions 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 free trial if you have taken one (its plan, when it started and ended, and when we emailed you that it had ended), 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 the customer and contains no 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 address, we send a one-time sign-in link, and opening it starts a signed-in browser session. We store:

• 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. The invitation names the account that sent it.

We send sign-in links by email through our mail provider. For a successful send we record the recipient, time and message id, without the link, so no usable copy of the token stays on our servers. If a send fails, we write the link to an operational log so we can deliver it by hand, and we purge those entries after 30 days. The email telling you a free trial has ended is sent and recorded the same way, as is the usage alert: a message to the account contact when a key's daily use reaches three times its recent average, or when a plan passes 80% and then 100% of a quota. The alert carries that day's counts by surface and a link to your dashboard, where you can switch it off.

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 public pages (the studio, the documentation, pricing and these legal documents) to see which pages are used. We use Umami, self-hosted on our own server, so no third-party analytics service is involved and nothing is shared with an advertising network. Your browser sends each page view to our public origin, which forwards it to our analytics server over an encrypted connection, with the IP address used for the daily code described below.

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 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, the dashboard and the sign-in link page, whose address carries a single-use token.

2.10 Cinematic clips

The Cinematic tab of our studio renders a short MP4 clip of one item. To start a render you sign in with your email address, as in 2.7. Each email address may start one render, and each IP address three, in any 24 hours. An account on a paid plan may start three renders in any 24 hours instead of one. A render started by a paid account does not count toward its IP address's three, and the IP address's three do not stop a paid account. A render that fails on our side, or that you cancel before it starts, is given back and does not count.

For each render you ask for, we store one record holding:

• the email address you signed in with;
• a hash of your IP address, made with the same secret key as the daily count in 2.1. The address itself is not stored;
• what you set in the tab: the item (weapon, finish, wear, pattern seed, StatTrak counter, stickers, charm and any name tag) and its name, the shots, the backdrop and the video settings;
• the render's progress: its state, when it was asked for, started, ready and finished, its frame count and file size, which of our render machines drew it, the reason if it failed, and whether it was given back; and
• whether your account was on a paid plan when you asked for the render, which decides how the render counts toward the allowance above.

We use the record to count the allowance above, to show you the clip's place in the queue and its progress, to send the emails below, and to answer questions about a render. We delete it automatically 7 days after you asked for the render.

We render each clip on a render machine we run ourselves. It receives what you set in the tab, over an encrypted connection, and nothing about who you are, and it deletes its own copy of the clip once our server has fetched it. No third party receives your render. The finished file is stored on our server under a link that contains a random value that cannot be guessed, and anyone who has the link can watch or download the clip. We delete the file automatically 1 hour after it is ready, and the link stops working at that moment.

We email the address that asked for the render when the clip is ready, with its link and the time the file will be deleted, or when the render failed on our side or could not start, saying that the render was given back. These emails go through our mail provider and are recorded the same way as the sign-in links in 2.7.

To limit how often one browser asks the tab for its catalog and its queue, we count those requests in memory, by IP address or by sign-in session. The count is never written to disk, and an address is dropped within 25 hours of its last request.

2.11 Inspekt Lens

Inspekt Lens is our browser extension (Terms 3.6). It reads the listing data that a supported marketplace's page has already loaded in your browser, and it sends that marketplace no request of its own. It sends us the item's parameters (its catalog id, float, pattern seed, stickers, charm, StatTrak count and name tag, or its inspect link) and your account's secret key (Terms 2.10), and it fetches our list of items once a day. Those requests carry no page address and no cookies. Each request is recorded as a usage event under 2.1, against your account.

When you open an item in 3D, the extension opens our embed (2.2) in a frame over the marketplace page, with the item's parameters and a token it makes from your secret key that expires within an hour. That request names the marketplace's website, for example https://csfloat.com, and no other part of the page's address, and it is recorded as an embed load under 2.1, against your account.

The extension keeps your secret key, its settings and the images it shows in your browser's own extension storage on your computer, the images for 24 hours. We cannot read any of it, and removing the extension deletes it.

2.12 Pro Studio

Pro Studio is the part of our studio at /pro with lighting, posing, background and capture tools (Terms 5.1). The background images, videos and logos you add to it stay in your browser. Your browser reads them from your computer and keeps them in its own storage on your device, with the looks you save, and none of them is sent to us. We cannot see them. Clearing your browser's site data for inspekt.gg deletes them. Captures are made in your browser and saved to your device. Whether your account may open Pro Studio is read from your account, as the rest of the studio reads it.

2.13 Share links

When you press Share, we save the item's setup (catalog id, float, pattern seed, stickers, charm, StatTrak count, name tag, backdrop and lighting) so the link keeps opening. The saved setup holds no account, address or cookie, and we keep it for as long as the link exists. The link is a short address, such as inspekt.gg/s/k7Qx2ab, and the same setup saved twice is one link. An inspect link pasted after inspekt.gg/ is saved the same way.

Each IP address may save 300 new links in a day, and a long share link, the /s/ address that carries the whole setup, gets its custom picture for 300 page loads in a day. Both are counted by the visitor address in the daily count in 2.1, so only a hash of the address is kept, and it is deleted after 3 days.

3. What we do not do

• No advertising trackers or pixels anywhere, and no tracker of any kind inside the embed.
• No sale of 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 in 2.9 changes every day.
• No third-party analytics service. Our analytics are self-hosted.
• No retained database of Steam inventories beyond the 5-minute cache in 2.4.
• No password for the dashboard.

4. Purposes

We process this data to enforce quotas and handle billing; to run, secure and debug the service; to prevent abuse; to sign you in to your dashboard; to render the clips you ask for and count them against the allowance in 2.10; and to meet legal obligations. The per-IP limit in 2.4 prevents abuse, including excessive requests to Steam.

5. Sharing

• Steam and Valve. An inventory lookup or inspect-link request means we query Steam's public service on the caller's behalf.
• Our mail provider, which delivers our emails, such as sign-in links, the notice that a free trial has ended and the emails about a clip in 2.10, and so 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 analytics in 2.9 are self-hosted, and no third party receives them.
• No render service. The clips in 2.10 are rendered on a machine we run, and no third party receives what you ask for.
• 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. Retention

The service deletes usage logs automatically after 13 months, which covers a full year of billing history plus the month in progress.

We take an encrypted off-site backup every night, holding the account and usage records described above, the render records in 2.10 and the saved share links in 2.13, but not the clip files. Backups are overwritten on a rolling schedule, so a deletion can take up to 90 days to reach every copy, although it takes effect immediately in the live service.

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 do not hold any security certifications.

8. Your rights

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 usage data in 2.1, which is anonymous by design.

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 in the dashboard. That removes the account record, its API keys and its sign-in sessions from the live service immediately, 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 linked to you, because the account record was the only link between a key and a person. The render records in 2.10 hold your email address, so they stay linked to you until their 7 days are up. 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 an active subscription must cancel it before the account can be deleted.

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. Data location

We are based in the United States and process the data described here in the United States. If you use the service from outside the US, your data is transferred to the US.

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.