How TuitionDesk Protects Your Enquiry Form From Spam

A public enquiry form has to be public — no login, no CAPTCHA friction, one tap for a parent to reach you. That openness is exactly what makes it a target. Bots crawl the internet submitting garbage into every open form they find, and a single bad actor can hammer an endpoint hundreds of times a minute just to see what breaks.

TuitionDesk's enquiry API (the same endpoint behind your iframe embed, your public site's form, and any custom integration) is protected by two separate limits, each guarding against a different kind of abuse.

Limit 1: Per-IP rate limit (anti-bot)

Every submission to POST /api/public/{your-slug}/enquiry is checked against the IP address it came from: no more than 5 submissions per hour from the same IP.

This is the classic anti-spam guard. It doesn't care which centre is being targeted — it stops a single bot or script from hammering any enquiry endpoint, yours or anyone else's, at machine speed. A real parent filling in your form once is nowhere near this limit. A script trying to flood your pipeline hits it on the sixth attempt and gets a 429 Too Many Requests with a Retry-After header telling it (and any legitimate retry logic) exactly when to try again.

Limit 2: Per-plan daily cap (org-level)

The second limit is different: it caps how many enquiries your centre's form can accept in a single day, scaled to your plan.

This exists for a different reason than the IP limit. Even if an attacker spreads their spam across many IP addresses (defeating the per-IP limit), this cap still stops your Admissions pipeline from being flooded with hundreds of fake leads that would bury your real ones and cost you time to clean up. It resets at midnight in your centre's local timezone — not UTC, not India time by default, whatever timezone your organisation is configured for.

What happens when a limit is hit

Both limits return a clear response so your embedded form (or custom integration) can show the parent something sensible instead of a silent failure:

• IP limit hit: 429 Too Many Requests — "Too many submissions. Please try again later."
• Daily cap hit: 429 Too Many Requests — "This centre has reached its daily enquiry limit. Please try again tomorrow or contact them directly."

Genuine enquiries are never silently dropped — the parent always sees a message, and if they need to reach you urgently, your WhatsApp button (shown on every TuitionDesk enquiry form when you have a WhatsApp number set) still works regardless of the form's limits.

Why this matters if you're building a custom integration

If you're posting to the enquiry API directly instead of using the iframe (see our guide on embedding the enquiry form), build your integration assuming both limits exist:

• Don't retry aggressively on a 429 — respect the Retry-After header
• Don't build a "test script" that hits the endpoint in a loop during development — you'll burn your own daily quota
• If you're running a legitimate high-volume campaign and expect to exceed your plan's daily cap regularly, upgrade rather than architecting around the limit — it's there by design

The bigger picture: why this protects you, not just TuitionDesk

An unprotected public form is a liability two ways: bots can use it to spam you with junk leads, and a compromised or malicious script could theoretically use it to spam others by embedding fake contact details in the message field. Rate limiting closes both doors without adding any friction — no CAPTCHA, no login, no delay — for the parents actually trying to reach you.

Building on top of TuitionDesk's public API? Get your API access and see the full enquiry form embed guide — protected by default, no extra setup needed.