Acceptable Use Policy

1. Who this applies to, and what you are responsible for

Your obligations extend to everything done through your account, because we cannot see who is at the keyboard.

• You are responsible for all activity under your account and under every API token issued to it, including activity by your employees, contractors and end users.
• If you embed the widget or resell quoting through our API, your own customers are your responsibility. They are not our users, we have no contract with them, and we will address you rather than them.
• You must keep your credentials confidential. API tokens are bearer credentials: anyone holding one can act as you. If a token may have been exposed, rotate it from the dashboard immediately — rotation issues a new secret and retires the old one — and tell us.
• You must be at least 18 years old to hold an account.
• If you become aware of misuse of your account, tell us at [email protected]. Telling us promptly is treated in your favour, not against you.

2. Limits that are enforced automatically

These are technical limits, not judgements about you. Hitting one is not a breach of this policy — the system simply declines the request and tells you why.

Working within a limit is legitimate use, including running right up against it. What is not legitimate is trying to get around one — see section 4.

We may change these limits. Where a change would reduce what you can do, we give the notice described in section 19 of the Terms of Service.

• Upload size. Files above the configured maximum are rejected at upload. The rejection names the limit that applied, so you never have to guess it.
• Model complexity. Files above the configured triangle count are rejected, because analysing them would exhaust the memory budget of a single quote. The rejection names both your model's count and the limit.
• File format. Only STL, OBJ and 3MF are accepted. Anything else is rejected at upload.
• Storage quota. Each plan has a storage allowance. When it is full, further uploads are declined until you delete files or move to a larger plan.
• Request rate. API requests are rate limited per token. Responses carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers so your integration can pace itself, and a rejected request returns HTTP 429 with a Retry-After value.
• Token restrictions. A token may be scoped to particular endpoints, bound to particular origins, restricted to particular IP addresses, and given an expiry date. Widget tokens are published in your public pages and should always carry scopes and an origin restriction.

3. What you must not upload or submit

You must have the right to give us every file you upload, and the file must not be one of the following.

• Content you have no right to process — a model covered by someone else's intellectual property, a design you received under a confidentiality obligation, or anything you are contractually barred from sending to a third party.
• Content whose manufacture or distribution is unlawful where you are, where we are, or where it will be printed. Firearms and firearm components are the obvious case; so are items restricted by export control or sanctions law.
• Malware, or a file crafted to exploit a parser rather than to be printed.
• Personal data that has no business being in a 3D model file. We do not need it, we do not want it, and putting it there makes you its controller without a lawful basis for the transfer.
• Special categories of personal data under Article 9 GDPR — health data in particular. Anatomical models derived from a patient scan are a real use of this technology and a real risk: if you send them, you must have your own lawful basis, and you should tell us in advance so that the Data Processing Agreement is in place first.
• In the AI assistant, do not paste national ID numbers, card numbers, passwords or API tokens. The assistant is a support tool; those values are never needed to answer a question, and the conversation is stored.

4. What you must not do to the service

These rules protect the service for everyone using it.

• Do not work around a technical limit — by splitting requests across tokens or accounts to defeat a rate limit, by sharing one account between separately billed organisations, or by using the free plan to serve a production workload.
• Do not attack the service: no denial of service, no attempt to access another tenant's data, no probing for vulnerabilities without our written permission. If you find a vulnerability by accident, section 7 tells you what to do, and doing that is welcomed rather than punished.
• Do not scrape the service or use it to build a competing quoting engine, and do not extract our pricing profiles, machine profiles or material data as a dataset.
• Do not misrepresent our output. A quote is an estimate, as section 9 of the Terms of Service explains. Presenting one as a binding price from us, or as a guarantee that a part can be printed, is not something we permit.
• Do not imply a partnership, endorsement or certification that does not exist, and do not use our name or marks in a way that suggests we produced or approved your own output.
• Reverse engineering. You may not decompile or disassemble the service, except to the extent that mandatory law allows it and no agreement may restrict it — in particular the interoperability rights in Articles 5 and 6 of Directive 2009/24/EC. We state that exception explicitly because a blanket prohibition would be unenforceable against it anyway, and we would rather be accurate than broad.

5. If you build on the API or the widget

Reselling or embedding quoting is an intended use of the service. These are the conditions.

• Your own users must be given your own terms and your own privacy notice. We are your processor for the files they send, on the terms of the Data Processing Agreement; we are not their service provider.
• Do not present the widget in a way that hides that a quote is an estimate, or that suppresses an error the API returned.
• Pace your integration against the rate limit headers rather than retrying in a tight loop. A retry storm is indistinguishable from an attack, and it is handled the same way.
• Keep your webhook endpoints able to accept our deliveries. We retry a failed delivery a small number of times with increasing delays and then stop; we do not hold undelivered events indefinitely.

6. What happens when a rule is broken

We would rather solve a problem than close an account, so the response is graduated and normally starts with a conversation.

• Automatic throttling. An integration that exceeds a rate limit is slowed, not punished. Nothing is recorded against you.
• Notice. For anything beyond that, we contact you first, describe what we saw, and give you a reasonable opportunity to fix it — unless the law requires us to act immediately, or unless waiting would cause serious harm to another user or to the service.
• Restriction. We may disable a specific token, block a specific origin, or suspend a specific capability while a matter is resolved, rather than disabling the whole account.
• Suspension. We may suspend the account. Suspension stops access; it does not delete your data and it does not by itself end your subscription.
• Termination. We may terminate for a serious or repeated breach. If we terminate, the refund rules in our Cancellation and Refund Policy still apply to the period you have paid for.
• Whenever we restrict, suspend or terminate, we tell you what we did, why, which rule it relied on, and how to challenge it. Write to [email protected] and a person will review it. If we got it wrong, we reinstate and say so.
• Unless the law forbids it, we keep your data for at least 30 days after a suspension or termination, and the export in your dashboard settings keeps working throughout, so you can take a copy without asking us. We do not use data loss as a sanction.
• Nothing in this section limits your statutory rights, and nothing in it requires you to complain to us before going elsewhere.

7. Reporting abuse and security problems

One address for both, so that nobody has to guess: [email protected]. We acknowledge within 5 business days.

• Report content. If you believe something stored or produced through the service is unlawful or infringes your rights, tell us what it is, where it is, why you say so, and how to reach you. We will look at it, tell you what we decided, and tell you why.
• Report a vulnerability. Tell us what you found and how to reproduce it. Please give us a reasonable period to fix it before publishing. We will not pursue you for a report made in good faith that did not access other users' data, did not degrade the service and did not go further than necessary to demonstrate the problem.
• Report a wrongly restricted account. Say what was restricted and why you think it should not have been. This route goes to a person, not to an automated system.
• We do not operate a paid bug bounty. We say so plainly rather than leaving researchers to find out afterwards.

8. Changes to this policy

We update this policy when what we enforce changes. The date it took effect is shown at the top of this page, and each version has its own identifier so that a past version can be identified.

If a change would meaningfully restrict what you are currently allowed to do, we give you at least 30 days' notice before it takes effect, and you may terminate without penalty within that period.

Questions about this policy: [email protected]. Reports under it: [email protected].