The quick version: Web-to-Case accepts up to 5,000 cases per day per org. Requests beyond that go into a pending queue and are processed when the daily allowance resets, and once that queue is full the rest are discarded. The bigger practical problem is not the cap, it is that the endpoint is an unauthenticated public form and spam bots find it within weeks.
How it works
You generate an HTML form in Setup. It posts to a Salesforce endpoint with a hidden field carrying your org ID, plus one input per case field you chose. Salesforce receives the post and creates a case. There is no authentication, no API token, and no session.
The daily limit and what happens past it
The cap is 5,000 cases per day, counted per organisation, and it is not raised by buying more licences. It resets daily.
Past the cap, requests are not immediately rejected. They go to a pending request queue and are submitted as the allowance becomes available the next day. That queue has its own ceiling, and requests arriving after it is full are dropped with no case created. Salesforce notifies the default case owner when this happens, which is the only warning you get, so make sure that address goes to a monitored inbox rather than a departed administrator.
Required fields and silent failures
The generated form only contains the fields you ticked. Everything else on the case is untouched, and that includes anything your org made required or anything a validation rule depends on.
If the case fails to save, the request does not bounce back to the web visitor with a helpful error. The visitor sees your success page. Salesforce sends an error notification to the address configured in the Web-to-Case settings, and the case does not exist.
Two defences. Make the form carry a value for every field your validation rules touch, using hidden inputs with defaults where the visitor should not be asked. And exclude web-origin cases from validation rules that agents need but web submissions cannot satisfy:
AND(
NOT(ISPICKVAL(Origin, 'Web')),
ISPICKVAL(Priority, ''),
NOT(ISNEW())
)Spam
An open endpoint attracts automated submissions. The usual pattern is a few hundred cases a day with a plausible name, a real-looking email address and a body full of links.
What works, roughly in order of effectiveness:
- Do not post directly to Salesforce from the public page. Post to your own server or a serverless function, validate there, then forward. This is the single biggest improvement and it also gives you a place to log rejections.
- A CAPTCHA on your page, verified server side before forwarding. A CAPTCHA that is only checked in the browser stops nothing, because the bot posts to the endpoint directly.
- A honeypot field hidden with CSS. Bots fill it, humans do not. Cheap and surprisingly effective against low-effort bots.
Things the form does and does not do
Assignment rules always run on Web-to-Case, whether or not anybody asked for them. So does the auto-response rule, if one is active, which is why an unprotected form turns into an outbound email generator.
The Origin field is set from a hidden input in the generated form, and it is the only reliable way to tell web cases apart later. Do not let anyone repurpose it.
When to use something else
Web-to-Case is right for a simple public contact form on a marketing site. It is the wrong tool once you need authentication, file uploads, validation feedback to the user, or a case number shown on screen. For a signed-in customer, an Experience Cloud site creates cases through the normal record path and none of the limits above apply.
Frequently asked
Can I raise the 5,000 limit? No. If you legitimately exceed it, move the volume to the API.
Does Web-to-Case create a contact? No. It captures the name, email and company as text on the case. Matching them to a contact is something you build, usually a flow on case creation.
Can I attach a file through the form? Not through the standard generated form. Handle uploads on your own page and post them to Salesforce separately.
