Salesforce Web-to-Case: Setup, Limits & Best Practices

Web-to-Case is a Salesforce Service Cloud feature that generates an HTML form for your website; when a visitor submits it, Salesforce creates a Case record from the submitted data. It is the support-side counterpart to Web-to-Lead, it needs no code on the Salesforce side, and it ships with a default limit of 5,000 Web-to-Case requests per org per day. This guide covers the full setup, the generated form, routing, spam control, and how it compares to Email-to-Case.

Key takeaways

• What it does: Captures support requests from a public web form and writes them straight into the Case object in Salesforce.
• Where to set it up: Setup → Service → Web-to-Case (search "Web-to-Case" in Quick Find), then generate the form under the Web-to-Case HTML generator.
• Daily limit: 5,000 requests per day per org — distinct from Web-to-Lead's 500/day cap.
• Required fields: The generated form must include Contact Name (or email) and Subject; the hidden orgid field is mandatory.
• Routing: Use case assignment rules to auto-route new cases; use auto-response rules to send branded acknowledgement emails.
• Spam control: Enable the optional reCAPTCHA, add validation rules, and consider posting the same fields from a custom front end instead of the raw, unstyled form.

What is Web-to-Case in Salesforce?

Web-to-Case is a standard Service Cloud capability that lets you embed a support form on your public website. Each submission is converted into a Case record — the object support agents work from — without anyone re-keying the request. Because the form posts directly to a Salesforce endpoint, you do not need an API integration or any server-side Apex to capture the data.

The feature exists to remove friction from intake: instead of customers emailing a shared mailbox or calling, they fill in a structured form, and the resulting Case lands in the right queue with the right priority and origin already set.

How do I enable Web-to-Case?

1. Go to Setup, type Web-to-Case in the Quick Find box, and open Web-to-Case.
2. Tick Enable Web-to-Case.
3. Set the Default Case Origin (for example, Web) so every captured case is tagged with its source.
4. Choose a Default Response Template — the email auto-sent to customers whose case does not match a specific auto-response rule.
5. Optionally enable Hide Record Information so failure-notification emails do not leak record data, and set an Email Signature for those notifications.
6. Click Save.

The Default Case Origin and response template are what make captured cases feel handled the moment they arrive, so set both before you publish the form.

How do I generate the Web-to-Case HTML form?

From the Web-to-Case area, open the Web-to-Case HTML Generator:

1. Move the fields you want from Available Fields to Selected Fields with the add/remove arrows, and order them with the up/down arrows. You can include custom fields too.
2. Provide a Return URL (retURL) — the page the visitor is redirected to after submitting (typically a "thank you" page).
3. If you use record types, add the Case Record Type picker so submitters land on the right process.
4. To reduce spam, enable reCAPTCHA and supply your reCAPTCHA API key pair, then choose the language.
5. Click Generate, copy the HTML, and hand it to your webmaster.

What does the generated form look like?

The generated markup posts to the Salesforce Web-to-Case endpoint and carries a few hidden fields:

<form action="https://webto.salesforce.com/servlet/servlet.WebToCase?encoding=UTF-8" method="POST">
  <input type="hidden" name="orgid" value="00Dxxxxxxxxxxxx" />
  <input type="hidden" name="retURL" value="https://yoursite.com/thank-you" />

  <label>Contact Name</label>
  <input type="text" name="name" required />

  <label>Email</label>
  <input type="email" name="email" required />

  <label>Subject</label>
  <input type="text" name="subject" required />

  <label>Description</label>
  <textarea name="description"></textarea>

  <input type="submit" value="Submit" />
</form>

Key points about this markup:

• action always targets https://webto.salesforce.com/servlet/servlet.WebToCase?encoding=UTF-8.
• orgid is your 15- or 18-character Org ID and is required — without it the case is not created.
• retURL is optional; omit it and the user stays on the Salesforce-hosted confirmation.
• The raw form is completely unstyled. Most teams reskin it with their own CSS, or POST the same field names from a custom front end (React, a CMS form, etc.) to match their brand.

Which fields are required?

Field	API name	Required?	Notes
Org ID	orgid	Yes	Hidden; identifies your org. Case fails silently without it.
Subject	subject	Yes	Primary identifier for the case in queues.
Contact Name	name	Yes	Name or email is needed to associate the case.
Email	email	Recommended	Required for auto-response and contact matching.
Description	description	Optional	Free-text detail of the issue.
Return URL	retURL	Optional	Redirect target after submit.
Case Record Type	recordType	Optional	Only if your org uses case record types.

Any field marked required on the Case object must carry a value, or the submission fails. Salesforce does not support Rich Text Area (RTA) fields on Web-to-Case forms — RTA input is stored as plain text.

Web-to-Case vs Email-to-Case vs On-Demand Email-to-Case

Web-to-Case is one of three form/email intake channels in Service Cloud. Pick by where your customers already are and how much infrastructure you want to run.

Capability	Web-to-Case	Email-to-Case	On-Demand Email-to-Case
Intake method	HTML form on your site	Inbound email	Inbound email
Requires an agent/email service	No	Yes (local agent behind firewall)	No (Salesforce-hosted)
Handles large attachments	No	Yes	Limited by email size
Daily volume cap	~5,000 requests/day	High	High
Best for	Structured website intake	Large attachments / on-prem control	Email intake without infrastructure

If email is your preferred channel, see how to set up On-Demand Email-to-Case. For real-time conversations rather than asynchronous cases, Salesforce Live Agent web chat is the better fit. Web-to-Case lives in Service Cloud; if you are weighing which cloud you actually need, read the difference between Service Cloud and Sales Cloud.

How are submitted cases routed and acknowledged?

Two rule types do the work after a case is created:

• Assignment rules decide who or which queue owns the new case (for example, route billing cases to the Finance queue). Web-to-Case respects active case assignment rules.
• Auto-response rules send the customer a branded acknowledgement email based on conditions you set; unmatched cases fall back to the Default Response Template.

After assignment, escalation rules can bump an aging or breached case to a higher tier — see how to set up escalation rules in Salesforce. Combined, these rules turn raw form submissions into a triaged, SLA-aware queue.

Limits, spam, and duplicate handling

• Daily limit: Web-to-Case accepts up to 5,000 requests per day per org. Past that, additional requests are dropped and the Default Case Owner receives a notification email. (Web-to-Lead's separate limit is 500/day — do not confuse the two.)
• Spam: Enable the form's reCAPTCHA, add validation rules on the Case object, and filter obvious spam with web services or a custom front end before posting.
• Duplicates: Web-to-Case does not deduplicate on its own. Use duplicate/matching rules, or match the inbound email to an existing Contact, to avoid creating repeat cases.
• RTA fields: Not supported; treat all inputs as plain text.

Best practices for a production Web-to-Case form

• Reskin or rebuild the form. The generated HTML is unstyled. Either wrap it in your own CSS or POST the same field names (orgid, subject, email, etc.) to the Web-to-Case endpoint from a custom front end so it matches your site.
• Always send orgid and a retURL. The Org ID is mandatory; a return URL gives users a clean confirmation experience.
• Set Default Case Origin and a response template before going live so every case is tagged and acknowledged.
• Turn on reCAPTCHA and validation rules from day one — public forms attract bots immediately.
• Pre-build assignment and auto-response rules so cases never sit unowned.
• Monitor the daily limit and watch the Default Case Owner's inbox for overflow notifications.

MicroPyramid has delivered 50+ projects and worked with Salesforce since 2014 (12+ years). Our team builds and reskins Web-to-Case forms, wires up assignment, auto-response and escalation rules, and integrates intake with custom front ends. Learn more about our Salesforce consulting and development services.

Frequently Asked Questions

What is Web-to-Case in Salesforce?

Web-to-Case is a Service Cloud feature that generates an HTML form for your website. When a visitor submits the form, Salesforce automatically creates a Case record from the data — no API integration or Apex required on the Salesforce side.

How do I enable Web-to-Case?

Go to Setup, search Web-to-Case in Quick Find, open it, tick Enable Web-to-Case, set the Default Case Origin and a default response template, then Save. Generate the form separately in the Web-to-Case HTML Generator.

What is the Web-to-Case daily limit?

The default limit is 5,000 Web-to-Case requests per org per day. Beyond that, extra requests are dropped and the Default Case Owner is notified. This is separate from Web-to-Lead, which is capped at 500 requests per day.

Which fields are required on a Web-to-Case form?

The hidden orgid field is mandatory, and you need Subject plus a contact identifier (name or email). Any field marked required on the Case object must also have a value, or the submission fails. Rich Text Area fields are not supported.

How do I stop spam in Web-to-Case submissions?

Enable the optional reCAPTCHA in the HTML generator, add validation rules on the Case object, and consider posting the form fields from a custom front end where you can filter requests with web services before they reach Salesforce.

What is the difference between Web-to-Case and Email-to-Case?

Web-to-Case captures cases from a structured HTML form on your website, while Email-to-Case (and On-Demand Email-to-Case) creates cases from inbound emails. Use Web-to-Case for guided website intake and Email-to-Case when customers prefer email or send large attachments.