Acceptable use policy
Last updated 3 October 2026.
This policy is part of the Terms of service between you and Whisk. It says what you and your apps may not do on Whisk, what the platform measures automatically, and what happens when a rule is broken. It is written for the apps a business runs for itself and its customers; if you are unsure whether something is allowed, ask at support@whisk.run before you build it. Asking first is always cheaper than being frozen.
This policy applies to you, to everyone in your organisation, to your coding agents, to the people who use your apps, and to anything served from whisk.page or from a domain you point at Whisk. You are responsible for all of it.
1. Illegal and harmful content
You and the apps you run on Whisk must not store, serve, process or link to:
- Anything illegal where your app is used, or anything that helps someone else break the law.
- Material that infringes another person's copyright, trademark, patent, trade secret, privacy or publicity rights, or that you have no right to hold.
- Child sexual abuse material, or any sexual content involving a minor. We remove it on sight, preserve what the law requires, and report it to the authorities.
- Material that promotes or plans terrorism, or violence against a person or a group, or that incites others to it.
- Material that harasses, stalks, threatens or defames a person, or publishes their private information without consent.
- Malware, ransomware, exploit kits, credential dumps, or tooling whose purpose is to attack other people's systems.
- Content that deceives: phishing pages, fake sign-in screens, counterfeit goods, fraudulent offers, or impersonation of a person or an organisation.
- Sexually explicit material of any kind, whether or not it is lawful. Whisk is a platform for business apps and does not host it.
2. Abuse of systems and networks
You must not:
- Attack, probe or overload anyone's systems, including ours and those of other tenants: no scanning, brute forcing, denial of service, or attempts to escape the container or the network your app is given.
- Try to read, alter or interfere with another tenant's apps, data or traffic, or with the platform's own components.
- Test the security of the platform outside the Security disclosure policy, or the security of anyone else's systems without their written permission.
- Send unsolicited email, bulk mail or any marketing email through the platform's own email service. Platform email is for transactional messages to people who have a relationship with you: receipts, notifications, one-time codes, approvals. Marketing and bulk mail need your own provider, which you may connect on Team and above. Whatever provider you use, you must have a relationship with the people you write to, honour an unsubscribe at once, send from an address that is yours, never forge a header or a sender, never harvest addresses or buy a list, never relay through someone else's open server, and follow the law where your recipients are, including CAN-SPAM, the Privacy Act's unsolicited messaging rules, and for text, voice and push messages the consent and do-not-call rules that apply to them.
- Run an open relay, an open proxy, a VPN endpoint, a Tor node or exit, a public DNS resolver, or any workload whose purpose is to route someone else's traffic.
- Mine cryptocurrency, run a blockchain validator or miner, or run any workload whose main product is burnt CPU rather than a business function.
- Run a public file-sharing, torrent, streaming or media-download service, or use Whisk storage mainly to distribute large files to the public.
3. Abuse of the platform's resources and rules
You must not:
- Circumvent plan limits, abuse signals, throttles, quotas or any other control, including by spreading one workload across several organisations or by creating organisations to renew a free allowance.
- Use more resource than your plan allows in a way that degrades the Service for other tenants. Where usage is metered, run what you pay for; where it is bounded, stay inside the bound.
- Resell the Service as a hosting product of your own. An Agency plan lets you build and run apps for clients under their own organisations; it does not let you offer "hosting".
- Automate the dashboard or the API beyond the documented rate limits, or scrape the Service. A crawler you run on Whisk must identify itself in its user agent, obey
robots.txtincluding any crawl delay, and stop when asked. - Use the Service to benchmark it for a competitor, or to build a competing product from what you learn about its internals. Publishing an honest review of your own experience is fine.
4. Data and privacy
You must not:
- Collect personal data without a lawful basis, or use it for a purpose the people it is about would not expect.
- Put special-category data (health records, biometrics, criminal records, precise location about individuals, government identifiers, or payment card numbers you are not entitled to store) into an app on a plan that does not commit to the measures such data needs. Ask us first.
- Use the Service to run credentialled surveillance of people who have not consented, or to score, rank or profile people in a way the law where they live forbids.
- Ignore a request from a person your app holds data about. You are the controller of that data under the Data processing agreement; the request is yours to answer.
5. Signals the platform measures on its own
The platform watches for a small set of signals and records each one where it is noticed. They are visible to the operator and, where they concern your organisation, noted in your own audit log or told to your developers. They measure behaviour, never the content of your data:
| Signal | What it means | What the platform does |
|---|---|---|
| Email throttled | An app tried to send faster than the limits (20 recipients a message, 100 a minute, the plan's daily allowance). | The send is refused with an error the app can read; the signal is recorded. |
| Bounce or complaint rate | Too many messages from your domain bounce or are reported as spam. | Sending from that domain pauses automatically until the cause is fixed. |
| Run guard | Workflow events were refused for their rate, or held because the month's runs are used up. | The events are refused or held, the signal is recorded and your developers are told once. |
| CPU pegged | A container ran above 90% of its CPU for ten minutes. | Recorded; the app keeps running unless it is a repeated pattern that matches section 2.6. |
| Egress | An app sent more than a gigabyte in an hour. | Recorded; sustained or extreme egress may be rate-limited. |
| Disposable sign-up | A confirmation used a disposable or free-mail domain. | The confirmation is refused. |
Outbound port 25 is blocked for every app and there are no exceptions, so mail leaves either through the platform's email service or through your own provider's API or submission port. Other outbound traffic is rate-limited. An organisation that has not been confirmed, or that has no payment method, runs with lower resource, sending and egress limits than a confirmed one.
6. Consequences when a rule is broken
- Automatic controls. The signals in section 5 act at once and without notice, because they protect other tenants and the reputation every tenant's mail depends on. Each of them is reversible, and fixing the cause lifts the limit.
- Notice. Where a breach needs a person's decision, we email the owners, name the rule and the app, and give a deadline to fix it, normally 7 days. Where the breach is serious, still running, or a risk to other tenants or to people outside the platform, we act first and tell you at once afterwards.
- Freeze. We may freeze the whole organisation, or only the app or the function at fault. A frozen app shows a maintenance page and refuses deploys. We keep a freeze as narrow and as short as the problem allows. A freeze we impose for a breach does not start the deletion timeline, and it is lifted when the breach is remedied or the matter is resolved.
- Termination. For a serious or repeated breach we may terminate the organisation under the Terms of service. Export works throughout, unless the content itself is what the law forbids us to hand back.
- Reports to authorities. Where the law requires it, or where people are at risk, we report to the relevant authority and preserve what we must.
- Costs. Where your breach costs us a provider's fine, the loss of a sending reputation or the hours of an incident, we may charge you what it reasonably cost.
7. Appealing a decision
Reply to the notice at support@whisk.run, or write with the organisation slug and what you think we got wrong. A person reviews it, not an automated system, and answers within 5 business days. If we were wrong, we lift the measure and credit any time the freeze cost you on a paid plan. A decision about material we must report to an authority is not one we can reverse on request.
8. Reporting abuse
If an app on whisk.page or a custom domain served by Whisk breaks this policy, tell us at support@whisk.run with the hostname, what you saw, when, and, for a rights complaint, the information the Takedown process asks for. We acknowledge every report within 2 business days and tell you what we did with it.
Report a weakness in the platform itself through the Security disclosure policy instead.
9. Changes to this policy
Abuse changes shape, so this policy changes with it. We give 30 days' notice of a change that would make something you are already doing a breach, unless the law or an immediate risk to people requires the change sooner.
Contact: Whisk, Auckland, New Zealand, support@whisk.run.
See also: Terms of service · Privacy policy · Data processing agreement · Takedown process · Security disclosure policy