Change history
A dated record of every version of the five documents that make up the customer agreement, so that you can tell which text you agreed to and when it changed.
The short version. A version is a date, and all five documents always carry the same one. Changing any one of them makes a new version of the whole set, which is listed here with what moved. A superseded version stays published and linked from this page. For a material change you get at least 30 days' notice by email before it takes effect, under Terms section 16.
1. What is in the set
1.1 The customer agreement is five documents, and they are versioned together:
- Terms of Service
- Privacy Policy
- Acceptable Use Policy
- Service Level Agreement
- Refunds and Cancellation Policy
1.2 The Terms of Service is the main agreement and it incorporates the other four. Where the Terms and one of the other documents conflict on something the Terms address directly, the Terms win. Terms 18.1 says so, and this page does not change it.
1.3 Each of the other four says, in its own Changes section, that it is updated the same way the Terms are, under Terms section 16. The whole set therefore has one notice promise.
2. How versions work
2.1 A version is a date. There is no separate version number. The version is the effective date printed under the heading of each document, written out in full, for example 9 September 2026.
2.2 Every document in the set carries the same version. If you are holding five documents that do not all show the same effective date, one of them is not from the set and you should tell us.
2.3 A change to any one document creates a new version for the whole set. All five get the new effective date, including the ones whose text did not move. That way "the 9 September 2026 set" identifies exactly one body of text, and a reader does not have to work out which document changed when.
2.4 A correction that does not change meaning is still a version. A typo, a broken cross-reference or a renumbered section produces a new dated version, marked here as editorial, with what was corrected. We record these so that you do not find a difference between your copy and ours that this page does not explain.
2.5 The effective date is the date the version takes effect, not the date it was written. For a material change that date is at least 30 days after the notice described in section 4.
3. Where a superseded version lives
3.1 The previous text stays reachable. When a version is superseded, its full text stays published, unchanged, at a permanent URL, and the entry for that version in section 6 links to it. We do not overwrite a document and leave you with no way to read what you agreed to.
3.2 This page itself is only ever added to. An entry that has been published is not edited or removed afterwards, except to add the archive link described in 3.1.
3.3 There are nineteen versions today. The 9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 and 30 September and 3 and 20 October 2026 sets are all superseded, and each entry in section 6 links to all five documents as they read on the day that version was replaced.
3.4 If you need a copy of the version in force on a particular date and cannot find it here, ask us at hello@inspekt.gg and we will send it.
4. What we commit to telling you
4.1 The promise is Terms section 16, quoted here in full so that this page cannot be read as adding to it or watering it down:
16.1 We may update this agreement. We will post the new version with a new effective date, and for a material change, including a change to fees, the liability cap or the uptime commitment, we will give you at least 30 days' notice by email or another reasonable method first.
16.2 When a change takes effect, the dashboard asks you to accept it on the acceptance screen the next time you open the dashboard, and using the service after the effective date also means you accept it. If you do not accept a material change, end the agreement under section 10.2 before the effective date, and the old terms apply until then.
4.2 In practice:
- Email to the account contact on every account, at least 30 days before the effective date of a material change. We do not rely on a banner, a footnote or this page on its own.
- The email says what changed, in plain language, and links to both the new version and the one it replaces.
- A new entry here, published at the same time as the email, listing which documents moved and in what way.
- The old version keeps applying until the effective date, and if you end the agreement under Terms 10.2 before that date, it keeps applying to you until the agreement ends.
4.3 For a change that is not material we post the new version and record it here, without the 30-day notice period. Under section 2.4 it is still a new dated version.
4.4 The email address we use is the one on your account. The only thing this commitment needs from you is to keep that address current.
5. What does not create a new version
5.1 Only the five documents in section 1.1 are versioned here. The rest of the site is not part of the agreement, and changing it does not create a version:
- The documentation, including parameter tables and error codes.
- The Pricing page, the comparison page, and anything else that describes the product rather than governing it.
- The product itself. The changelog records what shipped and when.
5.2 The exception. Several numbers that also appear on marketing and documentation pages are written into the documents themselves: the plan prices, the monthly quotas and the origin limits are in Terms section 5, the uptime commitment is in SLA section 2, and the 7-day new content commitment is in Terms section 9. Changing any of those is a change to the agreement and gets a version and the notice in section 4, whatever else on the site changes with it.
6. Version history
26 October 2026, not material
Three changes, in the Terms of Service, the Privacy Policy and the Refunds and Cancellation Policy. A plan bought from this date is sold through Link, Stripe's reseller, which calculates and collects the tax on it and can also refund it. No fee, quota, origin limit, liability cap or uptime commitment moves, and no other document's text changes.
- Terms 5.5 says who collects the tax. A plan bought from 26 October 2026 is sold through Link, Stripe's reseller, which calculates and collects the tax on it at checkout. The rest of 5.5 now applies to a subscription started before then, and reads as it did.
- Privacy 2.8 names Link. Link receives the name, billing address and any tax ID given at checkout, under its own privacy policy. Privacy 5 lists it beside Stripe.
- Refunds 2.6 is new: refunds through Link. For a plan bought from 26 October 2026 you can also ask Link support for a refund. Stripe may refund it within 60 days of the payment in some cases, and gives any cooling-off period the law where you live requires, even where Refunds 2.1 says we would not refund.
What it costs you. A subscription you already hold is billed and taxed as before. On a plan bought from this date, the tax Link collects is shown at checkout before you confirm, and it may be tax that was not charged before in your country.
Why this is not material. It changes no fee, quota, origin limit, liability cap or uptime commitment, and nothing about a subscription already held. Tax was outside the fees under 5.5 before and still is, and Refunds 2.6 only adds ways to get money back. Section 4.3 therefore applies.
20 October 2026, not material
One change, in the Privacy Policy. It describes share links, which the Share button in our studio now saves on our server so that a short link keeps opening. No fee, quota, origin limit, liability cap or uptime commitment moves, and no other document's text changes.
- Privacy 2.13 is new: 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) and give it a short link such as inspekt.gg/s/k7Qx2ab. The saved setup holds no account, address or cookie, and we keep it for as long as the link exists. An inspect link pasted after inspekt.gg/ is saved the same way. An IP address may save 300 new links a day, and a long share link gets its custom picture for 300 page loads a day per address.
- Privacy 2.1 says both counts are kept in the per-visitor daily count: a hash of the address, deleted after 3 days.
- Privacy 6 has a new row, for the saved share link. The opening names saved share links among what the policy covers.
What it costs you. Nothing. Sharing is free and optional. The saved setup holds nothing about the person who saved it, and the only data about a visitor is the hashed daily count in 2.1.
Why this is not material. It adds a free feature a person may use or leave, and the data it describes is an item's setup with nothing about who saved it. The two new counts are the daily count Privacy 2.1 already described, kept the same way and deleted after the same 3 days. It changes no fee, quota, origin limit, liability cap or uptime commitment, and nothing about the data the service already held. Section 4.3 therefore applies.
3 October 2026, not material
A new plan, Lens, and the browser extension it is for, with Pro Studio and a larger cinematic allowance on the paid plans. No existing plan's fee, quota or origin limit moves, and the liability cap and the uptime commitment are as they were.
- Terms 3.6 is new: Inspekt Lens. The extension shows still images from the Render API over the listings of third-party marketplace websites and links each listing to our studio. You may use it with your secret key, on Lens or on any plan that includes renders. Its images are for your own viewing while you browse; do not keep them longer than Terms 3.5 allows, publish them, or let anyone else use your key with it. Each image counts as a render. We are not affiliated with, sponsored by or endorsed by those websites, and a website that changes so that the extension stops working on it is outside the SLA.
- Terms 5.1 lists Lens: $5 a month, 5,000
embed loads, 5,000 renders, and no inventory lookups or origins. 5.9 is new: Lens
includes renders through the secret key and embed loads for the 3D viewer the extension opens
over the marketplace websites it supports, and on no other website. The Inventory API refuses a
Lens key with HTTP 402 and
not_in_plan, as renders and lookups refuse the account's publishable key and tokens, consuming no quota. 5.2 names Lens among the plans that stop at their quota, and 5.8 offers it a free trial. - Pro Studio and a larger cinematic allowance. Terms 5.1 says every plan in the table includes Pro Studio and lets an account start 3 cinematic renders in any 24 hours where others start 1, and that a free trial opens Pro Studio and keeps the 1 render. 5.9 says the same of Lens. Privacy 2.10 says a paid account's renders do not count toward its IP address's three and are not stopped by them, and that the render record notes whether the account was on a paid plan. Privacy 2.12 is new: the background images, videos and logos added in Pro Studio stay in your browser and are never sent to us. SLA 1.1 leaves Pro Studio and the cinematic render queue outside the SLA.
- Terms 2.10 says where the secret key is kept: on your own server on a plan for a website, and in the Inspekt Lens extension on your own computer on Lens.
- The opening and Terms 1.1 name the extension as part of the service, and Terms 17.5 says a person may buy Lens for their own use.
- Privacy 2.11 is new: what the extension reads, what it sends us with your secret key, and what it keeps on your computer. The opening names it.
- SLA 1.1 covers the Render API on Lens and leaves out whether the extension works on a third-party website.
What it costs you. Lens is $5 a month if you choose it. Every other plan costs what it did, and adds Pro Studio and the larger cinematic allowance at no charge.
Why this is not material. It adds a plan and an extension an account may take or leave, and gives the existing plans more. It changes no existing plan's fee, quota or origin limit, the liability cap or the uptime commitment, and the extension sends us data only when a person uses it. Pro Studio keeps what a person adds to it in their browser. Section 4.3 therefore applies.
30 September 2026, not material
One change, in the Privacy Policy. It describes the data behind cinematic clips, the short videos of one item that the Cinematic tab of our studio renders. No fee, quota, origin limit, liability cap or uptime commitment moves, and no other document's text changes.
- Privacy 2.10 is new: cinematic clips. A person signed in with their email address may start one render in any 24 hours, and one IP address three. For each render we store the email address, a hash of the requesting IP address made with the same secret key as the daily count in 2.1, what was set in the tab, and the render's progress, and we delete the record 7 days after the render was asked for. The clip is rendered on a machine we run, and no third party receives the request. The finished file is stored on our server under a link that contains a random value, and is deleted 1 hour after it is ready. We email when the clip is ready and when a render fails or cannot start, and those emails are recorded the same way as sign-in emails. The tab's requests are counted in memory by IP address or by session, and an address is dropped within 25 hours of its last request.
- Privacy 2.5 lists the two new uses of an IP address: the render allowance, which keeps only a hash, and the request count. The service still writes no end user's IP address to disk.
- Privacy 6 has three new rows, for the render record, the clip file and the request count, and says the nightly backup holds the render records and not the clip files.
- The opening and Privacy 4, 5 and 8 follow it. The opening names the cinematic clips among what the policy covers. 4 adds rendering a clip and counting it against the allowance to the purposes. 5 names the clip emails among what our mail provider delivers, and says no render service receives a request. 8 says a render record holds an email address, so it stays linked to that person for its 7 days, after a deleted account as well.
What it costs you. Nothing. A clip is free and optional, and nothing in Privacy 2.10 is stored about a person who does not ask for one.
Why this is not material. It adds a free feature a person may use or leave, and the data it describes is collected only from a person who asks for a render. It changes no fee, quota, origin limit, liability cap or uptime commitment, and nothing about the data the service already held. Section 4.3 therefore applies.
24 September 2026, material
One change, in the Terms. An image from the Render API may be stored and shown for up to 24 hours, and is requested again after that. No fee, quota, origin limit, liability cap or uptime commitment moves.
- Terms 3.5 is new. You may store an image the Render API returns, and show it, for up to 24 hours from when we sent it, unless a written agreement with us allows longer. After that you delete your copy and request the image again, and each request counts under Terms 5.6. A viewer's browser keeping an image for as long as the response's cache headers allow is not storing it. The terms said nothing about a stored copy before.
What it costs you. An image you would have stored and shown for longer than a day is requested again after 24 hours, and each of those requests counts toward your plan's render quota.
Why this is material, and why there was no notice period. It limits what you may do with what the service returns, and Terms 16.1 promises at least 30 days' notice of a material change. On this date the only account that has accepted any version of these terms is our own, so the notice would reach only us, as it would have for the 21 September 2026 version.
23 September 2026, not material
A wording pass across all five documents, and the removal of the SLA's description of the servers the service runs on. No fee, quota, origin limit, service credit, liability cap or uptime commitment moves.
- SLA section 3 is removed, and so is Terms 7.2, which pointed to it. Both described our hosting and set no obligation. The sentence in SLA 4.1 saying that we have no third-party monitoring is removed with them. The uptime commitment, how it is measured, the exclusions and the credit schedule are unchanged.
- Sections renumbered. In the SLA, Measurement moves from 4 to 3, Exclusions from 5 to 4, Service credits from 6 to 5, New content from 7 to 6, Claiming a credit from 8 to 7, Sole remedy from 9 to 8 and Changes from 10 to 9. In the Terms, 7.3 is now 7.2. Every cross-reference in the set follows. Links to these sections use their names, so none of them changes.
- Terms 5.3 states the cache rule once. It said cached responses are never billed and still count toward quota. It now says a response served from cache counts toward quota like any other. Terms 5.2 already says no plan is billed per request or per unit, so what you pay does not change.
- Privacy 2.5 lists every use of an IP address that the rest of section 2 describes. It named the view hash in 2.2 and the rate limit in 2.4. It now also names the daily count per visitor address in 2.1 and the analytics code in 2.9.
- A wording pass across the five documents and /legal. Shorter sentences and headings, such as One unit for Terms 5.6, where it read What one unit is. Explanations of why a clause exists are cut where the clause stands without them. Terms 5.4 and Refunds 4.2 say billing period where they said billing cycle, the term Terms 5.1 defines. No obligation moves.
What it costs you. Nothing. What you pay, what a plan includes and what we commit to are unchanged.
Why this is not material. It removes a description that set no obligation, renumbers sections, and rewords text without changing its meaning. Section 4.3 therefore applies.
22 September 2026, not material
Three changes, in three documents. An account may take a 10-day free trial of a plan, without a payment card. A key must name the site it is used from, and each key carries a daily limit on how much one visitor's address may use of it. And an account may hold a secret key and mint short tokens with it. No fee, quota, origin limit, liability cap or uptime commitment moves.
- Terms 2.3 also refuses a keyed request that names no
origin. It refused a request from an origin you have not registered. It now refuses a
request carrying a key and no origin at all, because the origin list is what protects a key that
travels in your page source. A browser sends the origin on every request an element makes, and
our loader and every documented snippet set
referrerpolicyso a page whose own referrer policy withholds it still sends one. - Terms 2.10 and 2.11 are new: the secret key and its tokens. An account may hold one secret key, shown once and kept by us only as a hash. It works from a server with no origin header and counts against the plan like the publishable key. A token is minted from it, lasts at most an hour, works where the publishable key works and is checked against the same origins. An account may switch on a requirement that its publishable key be refused, leaving tokens and the secret key. Both are optional and off for every account until it asks. 2.1 now says "your publishable key" where it said "an API key", because there is now a key it does not describe. Using tokens costs the same as the publishable key: one picture seen by one visitor is one count in 24 hours either way.
- Privacy 2.1 and 6 describe a daily count per visitor address. Each key limits how much any one visitor's address may use of it in a day. We store the UTC day, the key, the kind of request, a count, and a hash of the requesting IP address taken under a secret key, kept for 3 days. The address is written nowhere and the row holds nothing else about the visitor. Each account sets its own number, or switches the limit off, in its dashboard.
- Terms 5.8 is new: the free trial. Each account may take one free trial of Hobby or of any size of Pro, for 10 days (240 hours) from the moment it starts, with no payment card. During it the account has that plan's quotas, origin limit and support target, and owes no fee. Subscribing during the trial ends it and starts billing that day. When a trial ends without a subscription, the account has no plan and we email the account contact to say so. We may end a trial early, or decline to start one, where one customer uses more than one account to take more than one trial.
- Terms 5.7 and 5.1 follow it. 5.7 said there was no free plan and no trial. It now says there is no free plan, and lists an ended trial among the ways an account comes to have no plan. 5.1 counts the quota periods of an account with no subscription from the start of its free trial, if it has had one. It counted them from the account's creation, as it still does for an account with no trial.
- Privacy 2.6, 2.7 and 5 say what a trial adds. The account record holds the trial: its plan, when it started and ended, and when we emailed you that it had ended. That email goes through our mail provider and is recorded the way a sign-in email is.
- SLA 1.2 says a free trial earns no service credits, because it has no fee to take a credit from.
What it costs you. A trial is free and optional. An account that takes one has its quota period counted from the trial's start while it has no subscription, which puts the trial's 10 days inside one period.
Why this is not material. It adds an offer an account may take or leave. It changes no fee, quota, origin limit, liability cap or uptime commitment of any plan, and the account data it adds is the record of a trial the customer chose to start. Section 4.3 therefore applies.
21 September 2026, material
Four changes. The plan table rounds every fee up by a dollar and sells Pro in three sizes, where there were Pro and Scale. The plan lists in Terms 5.2 and 8.2, Refunds 7 and SLA 1.1 use the new names. Terms 16.2 says how a new version is accepted. Privacy 2.2 and 6 say what a restart of the service does to the embed view hash.
- Terms 5.1 has two plans, and Pro comes in three sizes. Hobby is $20 a month, where it was $19. The plan that was Pro at $99 is Pro · 500k loads at $100, and the plan that was Scale at $499 is Pro · 5M loads at $500. Each keeps the quotas and origin limit it had. Pro · 1.5M loads is new at $200 a month, with 1,500,000 embed loads, 375,000 renders and 150,000 inventory lookups a month and 20 registered origins. The unit price still falls at every step up the ladder. Terms 5.2 names Hobby and Pro as the plans whose quota is a hard cap.
- Terms 8.2, Refunds 7 and SLA 1.1 use the new names. Every size of Pro has a first-response target of one business day, as Pro and Scale had, and Hobby stays at two. The uptime commitment covers every plan with a monthly fee, as it did.
- Terms 16.2 says how a new version is accepted. It said that using the service after a change takes effect means you accept it. Since the 17 September 2026 version the dashboard has also asked you to accept each new version on its acceptance screen, the next time you open it, and 16.2 now says both in one sentence. What happens if you do not accept a material change stays as it was. Section 4.1 of this page quotes the new text.
- Privacy 2.2 and 6 say what a restart does to the embed view hash. They said the secret behind the hash was discarded whenever the service restarted, which counted a view inside its 24 hours a second time after each update. A planned restart of the service, such as an update, now carries the secret and the hashes over to the restarted service through the server's memory, and a reboot of the server discards both. 2.2 says the secret is never written to disk, where it said it was never written down, because a restart now hands it over in a file that is held in the server's memory. Each hash is still kept for 24 hours from the last view.
What it costs you. A new subscription costs a dollar more a month for the same quotas: $20 for Hobby, $100 for Pro · 500k loads and $500 for Pro · 5M loads. Pro · 1.5M loads adds a step between those two sizes at $200. An embed load inside its 24 hours now counts once across an update of the service, where it counted again after each one.
Amended in place on 21 September 2026. As first published, this version sold Pro · 500k loads as a plan of its own named Plus, beside two sizes of Pro. The same day the three became one plan, Pro, in three sizes, with no change to any fee, quota, origin limit, support target or uptime commitment. The version keeps its date because the only account that had accepted it was our own.
Why this is material, and why there was no notice period. The plan fees are on the list in section 5.2 of this page, so changing them is material, and Terms 16.1 promises at least 30 days' notice of a material change. On this date the only account that has accepted any version of these terms is our own, so the notice would reach only us. The 17, 18 and 20 September 2026 versions went without a notice period for the same reason.
20 September 2026, material
One change. A plan's quota now resets on the day of the month its subscription started, where it reset at 00:00 UTC on the 1st. No fee, quota, origin limit, liability cap or uptime commitment moves.
- Terms 5.1 counts quota per billing period. It counted per calendar month (UTC). A billing period starts on the day of the month the subscription started, at the same time of day in UTC, and ends when the subscription renews. In a month without that day, the period starts on the month's last day. Buying a plan for an account that has none starts a new billing period with the full quota, moving up a plan keeps the billing period, and an account with no subscription counts its periods from the moment it was created, unless an Enterprise agreement names another date.
- Terms 5.2 follows it. A spent quota stops its event kind for the rest of the
billing period, where it said the calendar month, and the
Retry-Afterruns to the start of the next billing period, where it ran to 00:00 UTC on the 1st. - Privacy 2.1, 2.6 and 6 follow it too. A usage event also holds the start of the billing period it counts toward. The account record holds the date its billing periods are counted from, which for a subscription is the date the payment processor bills it from. The usage totals kept for the life of the account are now kept per billing period as well as per month.
What it costs you. A plan bought on the 15th used to get a full quota from the 15th to the 1st and another from the 1st. It now gets one full quota from the 15th to the 15th of the next month, the same month its fee paid for, and a new one at each renewal after that.
Why this is material, and why there was no notice period. When a quota resets is part of what a plan includes. Terms 16.1 promises at least 30 days' notice of a material change, and the 18 September 2026 entry said the next material change would carry the full period. This one does not, for the reason that entry gave: on this date the only account that has accepted any version of these terms is our own, so the notice would reach only us. The new counting went live before this version's effective date for the same reason.
19 September 2026, not material
Two changes. Privacy 2.6 now lists what an account record holds, and a wording pass runs across the whole set. No fee, quota, liability cap or uptime commitment moves.
- Privacy 2.6 is corrected to the account record. It no longer lists overage settings, which went with overage on 18 September. It now also lists what the record already held and 2.6 left out: each key a rotation replaced, with the date it was retired; whether the account is an individual or an organisation; a quota or rate limit set for the account in place of its plan's; the date and version of the terms accepted; the reason for a suspension; and, on an account we set up by hand, a contact address and our notes. What we collect does not change, and Privacy 6 already set how long it is kept.
- Section 5.2 of this page no longer names overage rates among the numbers written into Terms section 5, because the 18 September version removed them.
- A wording pass across all five documents, the legal
index, and the summary box and sections 1 to 5 and 7 of this page. Sentences are shorter,
sentences that hid who acts now name the party, dashes and colon reveals are gone, and asides
sit in parentheses. It reworded:
- Terms: the opening, “The agreement”, 2.1 to 2.3, 3.2, the notes under the 5.1 table, 5.2, 5.4, 5.7, 6.1, 7.2, 8.2 and 17.5.
- Privacy Policy: the opening, 2.1, 2.2 and sections 2.4 to 8.
- Acceptable Use Policy: the opening, section 3, 4.13 and section 6.
- Service Level Agreement: the opening, 1.2, section 3 and section 7.
- Refunds and Cancellation Policy: 2.2, 3.1 to 3.4, 4.2, 6.2 and section 7.
Why this is not material. Nothing here changes what a plan costs, what it includes, what either of us owes, or the uptime commitment, and Privacy 2.6 now describes data the service already held. Section 4.3 therefore applies. Section 3.3 of this page is also counted up; it had not counted the 17 September 2026 set as superseded.
18 September 2026, material
One change, in two halves. A quota is now a stop rather than a bill, and Enterprise stops being a published plan. No fee, quota, origin limit, liability cap or uptime commitment on Hobby, Pro or Scale moves.
- Terms 5.2 is rewritten and its rate table is
gone. It used to say that on Hobby, Pro and Scale we keep serving past a quota and bill
the excess, and it carried a table pricing an embed load, a render and an inventory lookup per
1,000 units. It now says that a quota is a hard cap: once a quota for an event kind is spent,
requests of that kind are refused for the rest of the calendar month with HTTP 429 and the code
quota_exceeded, carrying aRetry-Afterthat runs to 00:00 UTC on the 1st. Each event kind is capped on its own, so spending the render quota leaves embed loads and lookups alone. Nothing beyond a quota is served and nothing beyond a quota is billed, and there is no longer any per-unit rate anywhere in the agreement: the monthly fee in 5.1 is the whole of what a plan costs you. 5.3 keeps its promise about cached responses and drops the words "as overage", which no longer mean anything. - What it costs you. On a plan whose quota you would have gone past, the service now stops for that kind until the 1st instead of continuing and charging for it. Your dashboard shows a bar per kind and says Paused until the 1st for one that has stopped; moving up a plan raises the cap on the next request. That is the trade: no invoice you did not expect, in exchange for no way to pay past a cap mid-month.
- Terms 5.1 no longer lists Enterprise, and it has no published fee or quota. Enterprise was the pay-as-you-go plan: $0 a month, nothing included, every request billed at the 5.2 rates. With those rates withdrawn there is nothing left to bill it by, so it becomes what its name says — the plan set by a written agreement between us, with its fees, its ceilings and its origin limit in that contract rather than on a page. It is uncapped by agreement, it is not self-serve, and it is arranged by email as it always was. Nobody is on it.
- Terms 6.1, Refunds 1.1, 1.2 and 2.2, Refunds 6.2 and SLA 1.2 and 6 follow it. 6.1 says the monthly fee is the only thing billed on a plan and that nothing is charged in arrears. Refunds 1.2 says there is no usage charge to refund, and 2.2 drops the usage-amount case with it. Refunds 6.2 keeps the per-key usage record and the promise to show it to you, now as the answer to "what was my account doing" rather than as the evidence behind a charge: we still count embed loads, renders and lookups per key and per month, and keep them as long as Privacy 6 says. SLA 1.2 and 6 say a credit is a percentage of a subscription fee, which Enterprise does not have.
Why this is material, and why there was no notice period. Withdrawing the overage rates and the published Enterprise terms are both changes to figures in Terms section 5, which section 5.2 above lists as an exception that always gets a version and notice. Terms 16.1 promises at least 30 days' notice of a material change to the account contact on every account. The 17 September 2026 set went live the evening before this one and no customer has accepted it; on this date the only account under any version of these terms is our own, so there was no customer to notify. The next material change carries the full period.
17 September 2026, material
Three changes in one version. Accepting the agreement becomes a step you take rather than something read into signing up. The Acceptable Use Policy gains a copyright complaints section with a named agent, which pushes three sections down by one number. And the Refunds Policy says how long a failed payment is retried before the subscription ends.
- Terms, “The agreement” says how you accept, and it is now a tick box. It used to say that creating an account, requesting a key or calling the service meant you accepted these five documents. From today you accept them on a screen the dashboard shows at your first sign-in: the five documents named and linked, one box that starts unticked, and a button that does nothing until you tick it. Nothing is accepted on your behalf at sign-up any more. Until you accept, the account gives you nothing — the key is not shown or issued, origins cannot be registered, no plan can be bought, nobody can be invited — and it keeps the two things you might want instead, which are signing out and deleting the account. The date and the version you accepted are recorded and shown in your dashboard, as before. When these documents change, the same screen asks again at your next sign-in. What it never does is stop serving you. Embeds, renders and inventory lookups on a key that is already working carry on regardless of what the paperwork says, because a missing signature is a paperwork problem and taking your embed off your customers' pages over one would not be.
- Acceptable Use 5 is new: copyright complaints. It names a designated agent to receive notices under 17 U.S.C. § 512, with a postal address and a copyright@inspekt.gg address, says what a notice has to contain to be effective, says that we act on a complete one expeditiously and tell the affected customer what was removed and why, keeps the counter-notice route open, and states that we terminate the accounts of repeat infringers. Nothing here is new about what you may do: infringing content was already prohibited by 4.12 and a breach of this policy was already grounds for termination under Terms section 10. What is new is the route in and the named policy behind it.
- Three Acceptable Use sections move down a number. Reporting a vulnerability was 5 and is now 6, Enforcement was 6 and is now 7, and Changes was 7 and is now 8. No word of any of the three changed. Nothing in the set cited them by number, and the links to them are unchanged because they are named rather than numbered. Section 2.4 above is why a renumbering is a version of its own.
- Refunds 5.1 says 14 days. It promised that your plan is not downgraded while a failed payment is being retried, without saying how long that is. Our processor retries a failed charge nine times over 14 days from the first failure and then cancels the subscription, and your plan and keys carry on for the whole of that time. 5.2 already covered what happens after. This is the number the service has always used, written down.
Why this is material, and why there was no notice period. No fee, quota, origin limit, overage rate, liability cap or uptime commitment moves, so nothing on the list in section 5.2 changed. It is recorded as material anyway for two reasons: the agreement is now formed by an act you take rather than by using the service, and Acceptable Use 5.5 names a termination policy that was not written down before. Terms 16.1 promises at least 30 days' notice of a material change to the account contact on every account. On this date the only account under any version of these terms is our own, so there was no customer to notify. The next material change carries the full period. Our own account is asked to accept this version at its next sign-in, on the same screen everyone else gets.
16 September 2026, material
Two changes in one version. The plan table is rebuilt: there is no longer a Free plan and there are three paid plans instead of five, Enterprise is now the pay-as-you-go plan, and no plan requires the Inspekt wordmark any more. Separately, an Inspekt account was one email address until today and can now be an organisation with several people on it.
- Terms 5.1 is a different table, and
Terms 5.7 is new. The plans are Hobby at $19 a month,
Pro at $99 and Scale at $499, plus Enterprise. The Free plan is withdrawn, and
so are Starter and the separate Pay as you go plan. Enterprise is what Pay as you go was: no
monthly fee, no included quota, and every request billed at the 5.2 rates from the first one,
against a card set up by email. Pro’s fee falls from $199 to $99 and its quotas halve, to
500,000 embed loads, 125,000 renders and 50,000 inventory lookups a month, with 10 registered
origins; Hobby and Scale keep the fees, quotas and origin limits they had. The unit price still
falls at every step up the ladder. 5.7 is the clause the withdrawal of Free makes necessary:
an account that has not chosen a plan — a new account, or one whose subscription has
ended — keeps its key, its origins and its usage records and is served nothing, refused
with HTTP 402 and the code
plan_required, and owes nothing while that is so. The public sandbox and the demonstration pages stay available with no account at all. 5.2 loses the sentence about throttling, because no plan is throttled at its cap now; 5.3 loses the half of its sentence that explained what Free throttling depended on. - No plan requires the wordmark. The corner badge was attribution the lower tiers were given in exchange for, and the higher ones could remove it. That rule is withdrawn: Terms 3.3 loses the bullet forbidding you to remove or obscure the wordmark on a plan that requires it, and the 5.1 table loses its Wordmark column. Nothing is newly required of you; one restriction is simply gone, and no plan is priced on it any more. The badge itself is still drawn on every embed, as the frame’s link into the studio rather than as a term of any plan, which is why Acceptable Use 4.9 still refers to it.
- Terms 8.2, SLA 1 and Refunds 1.1, 1.3, 3.3, 4.2, 5.2 and 7 follow the table. Support targets are two business days on Hobby and one on Pro, Scale and Enterprise. SLA 1.1 covers the plans with a monthly fee, and 1.2 puts Enterprise outside the uptime commitment for the reason it already gave about Pay as you go: a credit is a percentage of a subscription fee and Enterprise has none. The sentence worth reading is Refunds 3.3. It used to say that a cancelled account moved to the Free plan and was throttled rather than switched off. There is no Free plan to move to, so it now says what actually happens: at the end of the period you paid for, the account is left with no plan and the keys stop serving, which means an embed on your customer’s page shows a refusal card. The account, its keys, its origins and its usage history are all kept, and choosing a plan starts it serving again on the next request. Refunds 5.2 says the same about a subscription that ends after a failed payment.
- Terms 2.7 to 2.9 are new. An account is either an individual account or an organisation account, and you choose which when you create it. Either way the account is the customer: one plan, one key, one quota, one bill, and "you" in the Terms means the account. On an organisation account the owner can invite other email addresses, each with one of three roles. An owner can do everything, including deleting the account and handing it to another member; there is exactly one, and their address is the account's address for billing and notices. An admin can do everything except those two, which includes the key, the origin list and the plan, so an admin can change what you are charged. A member can see the plan, the usage and the origin list, can change nothing, and is never shown the key. 2.9 says plainly that what a member does on your account is done by you, that removing one ends their access immediately, and that we act on instructions from any member with the role to give them without checking with the owner first. Terms 18.4 follows: the address we send notices to is the owner's, and a notice sent there is given even if nobody reads it any more.
- Privacy 2.6 and 2.7 describe the records behind that, and Privacy 6 gains a row. An organisation account holds a member list: one email address, role, invitation date and acceptance date per person. An invitation that has not been accepted is that same record with the acceptance missing, so revoking one deletes it. Everyone on the account can see the list and nobody outside it can. A session now records which account it is signed in to as well as whose it is, which is what makes removing somebody from one account leave their access to another alone. An invitation is delivered by the same one-time link mechanism as a sign-in, held as a hash, and it names the account that sent it. The retention row says a member record lasts until the member is removed or the account is deleted.
Why this is material, and why there was no notice period. Fees, quotas and a plan table all moved, and every one of those is on the list in section 5.2. Terms 16.1 promises at least 30 days’ notice of a material change to the account contact on every account. On this date no agreement under any version of these terms was in force with any customer, so there was no contact to notify and nobody for the withdrawn plans to keep applying to. The next material change carries the full period. The organisation-account half of this version would not have been material on its own — it adds something you can choose to create and changes nothing about an existing account — and is recorded here because the two landed on the same day. One sentence in it is worth reading even so, because it is the one that can cost you money: an admin can change the plan, so an organisation account should have as few of them as the work needs.
15 September 2026, not material
Changes in three documents, all about where the service runs. No fee, quota, liability cap or uptime commitment moves.
- SLA 3.1 and Terms 7.2 describe the new hosting. The service moved from one self-hosted machine on a residential connection to a rented server in a United States datacentre, still with no automatic failover, with static assets delivered through a CDN. New Render API images are still drawn on one self-hosted GPU machine; while it is unreachable, images already rendered keep serving and new requests get a placeholder. SLA 3.3 named a CDN as a possible improvement, and now names a different one.
- Privacy 2.9 no longer says that no data about your visit leaves our origin. Page views travel from the origin to the server that runs our analytics, over an encrypted tunnel between two machines we run. What is collected does not change.
- Privacy 2.2 no longer says that every asset and API call the embed makes goes to our own origin. Its API calls still do; its textures, models and other static files come from cdn.inspekt.gg, our own name, served through a content delivery network. The embed still sets no cookies and makes no request to a third-party domain, and what viewing it collects does not change.
Why this is not material. Nothing here changes what a plan costs, what it includes, what either of us owes, or the uptime commitment, and SLA 3.3 already said a change to this infrastructure could only improve on 3.1. Section 4.3 therefore applies.
14 September 2026, material
Changes in four documents. We started keeping an encrypted off-site backup of the records this service runs on, and the Privacy Policy now says so. The plan table in the Terms gained three plans and moved two quotas, and the SLA and the Refunds Policy follow it.
- Privacy 6 gains a row and a paragraph, and Privacy 8 gains six words. Until 13 September nothing kept a second copy of the account and usage records, so section 8 could say that deleting an account removed it “immediately” and stop there. A nightly encrypted backup makes that sentence incomplete rather than wrong: deletion is still immediate everywhere the service reads, and a copy survives in the backup until that backup is overwritten. The retention table now carries this as its own row — 90 days at the outside — and section 8 says the same thing in the sentence that used to end at “immediately”. The 90 days is not an estimate: the backup keeps 14 daily and 12 weekly snapshots, which cannot hold anything older than 84 days.
- Terms 5: two quotas move and three plans join the table. The Free plan’s embed loads move from 5,000 to 1,000 a month. Starter’s move from 100,000 to 150,000 and its renders from 25,000 to 30,000, so that each step up the ladder costs less per unit than the step below it. The three new plans are Hobby at $19 a month, Scale at $499, and Pay as you go, which has no monthly fee and no included quota at all: every request it serves is billed at the 5.2 rates from the first one. Renders, inventory lookups, origins and the wordmark requirement on Free do not change, and neither does anything about Pro. /docs/pricing and /docs/limits carry the same numbers and are held to them by a test. Terms 8.2 gains a first-response row for each plan that had none: Hobby two business days, Scale one, Pay as you go best effort like Free, and Enterprise as its own agreement says. Starter and Pro keep the targets they had.
- SLA 1 and Refunds 1.1 follow those plans. SLA 1.1 lists the paid plans the uptime commitment covers, which is now Hobby, Starter, Pro, Scale and Enterprise. SLA 1.2 puts Pay as you go beside Free as best effort with no credits, for the reason 1.2 already gave: a credit is a percentage of the subscription fee for the affected month, and neither of them has one. Refunds 1.1 gains a sentence saying the same thing about the fee, and pointing at 1.2 for what is billed instead. Nothing any existing plan is owed changes.
Why this is material, and why there was no notice period. Quotas moved and plans were added, and a quota is on the list this page uses for a material change. Terms 16.1 promises at least 30 days’ notice of a material change to the account contact on every account. On this date no agreement under any version of these terms was in force with any customer, so there was no contact to notify and nobody for the old figure to keep applying to. The next material change carries the full period. The backup disclosure on its own would not have been material; it is recorded in the same version because the two landed on the same day.
13 September 2026, not material
Three changes, in three different documents, none of which moves a fee, a quota, a liability cap or an uptime commitment, and an editorial pass across the whole set.
- How we write about regulated customers. Terms 4.2 and
Acceptable Use 3 used to single out one trade by name
and say we serve it. That sentence did no work: what protects both sides is the set of warranties
underneath it, and those are unchanged. Both sections now read on any customer whose business needs
a licence, permit or registration, or is subject to age-verification, anti-money-laundering or
consumer-protection rules. Nobody is newly excluded and nothing is newly required.
Terms 14.2 follows the same move: the limb that named one
sector's law now names the obligation, which reaches strictly more than it did.
No section number moved; Acceptable Use 3 is still 3, which is what Terms 4.2 and
Privacy 9 cite. The link fragment did change, to
#regulated, so an old deep link into that section lands at the top of the page rather than at the section itself. - Terms 17.5 is new. 17.2 sends disputes to the courts in Salt Lake County, and 17.2 to 17.4 are written on the assumption that both sides are businesses — which this agreement had never actually said. If the law where you live treats you as a consumer and gives you a right you cannot waive, 17.5 says this agreement does not take it away. It gives something up and takes nothing.
- Terms 5.5 says how tax is worked out. Fees have always excluded sales tax and that has not changed. What 5.5 now adds is the mechanics: where we are registered to collect a tax it is calculated at checkout from your billing address, shown before you confirm, and itemised on the invoice; where we are not registered, the fee is the whole of what we charge. If you are tax-exempt, send us the certificate before you subscribe — tax already collected has already been remitted and we cannot refund it.
- An editorial pass across all five documents and this page. Wording only. No obligation, figure, date, section number, cross-reference or defined term moved. What was cut was sentences describing the writing rather than the agreement, such as the SLA's remark that 99.5% was not a headline number hiding a different reality underneath: SLA 3.1 still discloses the single self-hosted origin in full, which is the fact that sentence was commenting on.
Why this is not material. Nothing here changes what a plan costs, what it includes, what either of us owes, or what we promise about availability. Section 4.3 therefore applies and there is no 30-day notice period. One thing is worth saying plainly even so, because it can change the number on a card: when sales tax collection begins, an invoice in a state where we are registered will be the fee plus that state's tax. The fee is unchanged; the total is not the same number.
12 September 2026, not material
One addition to Terms 5.6, and one description of it in Privacy 2.2. Every plan is sold by the month in embed loads, renders and inventory lookups, and the agreement never said what one of those is. It does now, and for the embed the answer is more generous than the one our documentation had been giving:
- Terms 5.6 is new. An embed load is counted once per viewer, per item, per 24 hours. A page showing twelve different items is twelve loads; the same viewer reloading, scrolling back to something they have already seen, or returning to it later the same day is served and not counted again. Renders and inventory lookups are counted per request, which is what they always were. No existing clause number moved. The new text reads better as 5.2, but 5.2 through 5.5 are published numbers that other documents and other people's notes cite — Refunds 4.3 names Terms 5.4 — so it takes the next free number at the end of the section and 5.1 points at it.
- Privacy 2.2 says how a returning viewer is recognised, because counting one requires it. There is no cookie and nothing identifying is stored: the address and user-agent are hashed together with the customer's key and the item, under a secret held only in memory, and the result is kept for 24 hours and never written to disk. The customer's key inside the hash is what makes the same person on two different sites two unrelated values, so this cannot become a record of where anyone has been. The retention table in Privacy 6 carries it.
Why this is not material, and why it is dated tomorrow. It can only raise what a plan allows and lower what a bill says: no fee, quota, liability cap or uptime commitment moves, and nobody can be worse off under it than under the rule it replaces. Section 4.3 therefore applies and there is no 30-day notice period. The date is 12 September because a version is a date (section 2.1), 11 September already names the version published that morning, and rewriting the text behind a date somebody may already have accepted is the exact thing section 3 exists to prevent.
11 September 2026, editorial
A correction pass across all five documents, checking every figure and cross-reference in them against the code that has to honour it. Nothing here changes what anyone owes, is charged, or is promised, so it is not a material change and carries no notice period under section 4.3. Section 2.4 makes it a version regardless, and this is what it corrected:
- Terms 5.1 now says what Enterprise is. The table is a list of self-serve prices and deliberately does not carry a plan that has none, but an Enterprise customer was reading a heading that said "current plans" and finding nothing about theirs. A sentence under the table says the fees, quotas and origin limit come from a written agreement, and that everything else in the terms — the SLA included — applies to that account like any other.
- Terms 10.4 listed what survives termination as "sections 1 (as to definitions), 3.2, 3.4, 11, 12, 13, 14 and 17". The definitions are not in section 1 — they are in "The agreement", above it and unnumbered — and the list left out section 15, although 15.5 says in its own words that confidentiality survives three years and 13.3 carves it out of the liability cap. It now names the definitions where they actually are, and adds 15 and 18.
- Terms 18.1 said the whole agreement was these terms plus the Acceptable Use Policy, Privacy Policy and SLA. It is five documents: the preamble and 6.6 both incorporate the Refunds and Cancellation Policy, and section 1.2 of this page cites 18.1 as the authority for the set being five. The clause now lists it.
- Privacy 8 told you that deleting your account leaves the usage counts of Privacy 2.3 for thirteen months. Privacy 2.3 is the Render API. What outlives a deleted account is the usage records in Privacy 2.1, which is what the retention table cites.
- SLA 1.1 applied the uptime commitment to "a paid plan (Starter or Pro)", which read Enterprise out of it. It now covers every paid plan.
- SLA 2.1 said 99.5% allows "about 3 hours 39 minutes" in a 30-day month. Half a percent of 43,200 minutes is 216, which is 3 hours 36. The old figure was half a percent of an average month, and no month is an average one. It now gives the rule — 0.5% of the month — and the figure for a 30-day and a 31-day month.
- Refunds 7 promised a reply to billing email "within one business day", to everyone, where Terms 8.2 commits to one business day on Pro, two on Starter and best effort on Free. Terms 8.2 governed either way under 18.1; the Refunds page now quotes it instead of contradicting it.
- The closing "see also" on each document listed three of the other four. Five hand-written lists that each dropped something different is how the Refunds policy came to be unreachable from the foot of four documents that incorporate it. All five now list the other four and this page.
9 September 2026, initial publication
The first published version of the customer agreement. Nothing is superseded, because there is no earlier version. Five documents:
| Document | What it covers |
|---|---|
| Terms of Service | The agreement between you and Menu Atlas LLC, a Utah limited liability company: what the service does, accounts, keys and registered origins, the licence and its limits, plans, fees, quotas and overage, payment, the uptime commitment, support response targets, the 7-day commitment on newly released CS2 content, suspension and termination, our position on Valve and game content, warranties, the liability cap, indemnities, confidentiality, how the agreement changes, and Utah governing law. |
| Privacy Policy | Everything we collect, per surface, and what we deliberately do not: usage records that identify an account rather than a person, an embed that sets no cookies and calls no third party, inventory results held in memory and never written to disk, the retention table, who we share with, your rights, and where the data lives. |
| Acceptable Use | What you may build on the service and what you may not, including the limits on extracting or re-serving assets, our position on skin gambling and the conditions attached to it, how to report a vulnerability, and how the policy is enforced. |
| Service Level Agreement | The 99.5% monthly uptime commitment, a full description of the single self-hosted origin behind it, how downtime is measured, what does not count as downtime, the service credit schedule, how to claim, and that credits are the sole remedy for missed uptime. |
| Refunds and Cancellation | What a payment buys, when we refund and when we do not, how to cancel and when it takes effect, what happens to your keys and embeds afterwards, how upgrades and downgrades are timed, failed payments, and how to raise a billing problem. |
7. Contact
Send questions about any version, or a request for the text in force on a particular date, to hello@inspekt.gg.
Menu Atlas LLC
c/o Northwest Registered Agent LLC
7533 S Center View Ct Ste N
West Jordan, UT 84084, USA