REDA One Help Center
EN
Language
English EN Español ES Português PT Italiano coming soon Français FR Deutsch coming soon العربية coming soon
reda.one ↗
Home / REDA Connect / Getting Started / Creating the public Site for incoming messages

Creating the public Site for incoming messages

When a customer sends you a WhatsApp message or an SMS, WhatsApp (Meta) or Twilio has to deliver that message to your Salesforce org over the internet. They deliver it to a webhook — a web address in your org that can receive messages without anyone being logged in. In Salesforce, the way to expose such an address is a Salesforce Site: a public web endpoint attached to your org, used by a special limited user called the guest user.

REDA Connect does not create this Site for you — every org must set it up once, by hand, following the steps below. It takes about ten minutes. Without it, outgoing messages will still work, but nothing your customers send will ever reach Salesforce, and neither WhatsApp nor Twilio delivery receipts will arrive.

Before you start

Step 1 — Register your Sites domain (first Site in the org only)

Every org has one Sites domain — a web address that all its Sites share. If your org has never used Sites before, register it now; if a domain already exists, skip to Step 2.

  1. In Salesforce, click the gear icon (top right) and choose Setup.
  2. In the Quick Find box (top left of Setup), type Sites and click Sites under User Interface → Sites and Domains.
  3. If you see a screen asking you to choose a domain name, your org has no Sites domain yet. Enter a domain name — your company name is the usual choice. This name becomes part of the web address WhatsApp and Twilio will deliver to (for example yourcompany.my.salesforce-sites.com). It can never be changed once registered, so pick something you're happy to keep.
  4. Click Check Availability, accept the terms, and click Register My Salesforce Site Domain.

Expected result: the Sites page now shows your domain at the top and an empty list of sites.

The Sites page in Setup: the registered domain notice reading "Your Salesforce site domain name is reda-connect-dev-ed.develop.my.salesforce-sites.com", the Settings section, and the sites list showing a site labelled REDA Connect with its Active checkbox ticked
The Sites page with a registered domain — the notice at the top shows the domain all your Sites share, and the list below shows each Site with its Active flag. After Step 2, your REDA Connect site appears in this list.

Step 2 — Create the Site

  1. Still on Setup → Sites, click New.
  2. Fill in the new site form:
FieldWhat to enterWhy
Site LabelREDA ConnectDisplay name; anything recognisable works
Site NameREDA_ConnectSalesforce fills this automatically from the label
Site ContactLeave as yourselfReceives Site-related notifications
Default Web AddressLeave the suffix blank, or enter a short path like redaIf you enter a path, it becomes part of your webhook address — note down what you chose
ActiveTick itAn inactive Site returns an error page to WhatsApp and Twilio
Active Site Home PageClick the lookup and pick UnderConstructionRequired by Salesforce. Nobody will ever browse this page — the Site exists only to receive messages
  1. Leave every other field at its default and click Save.

Expected result: the Site's detail page opens, showing Site URL — an address ending in .my.salesforce-sites.com. Note this full URL down; you will use it in Step 4 and again when you connect WhatsApp and Twilio.

The Site detail page's action buttons — Edit, Public Access Settings, Login Settings, URL Redirects, Deactivate — and its Custom URLs section listing the Sites domain with the path /reda
The saved Site's detail page: the Custom URLs section shows the Domain Name and Path that together form your Site URL — note the full address down. The Public Access Settings button above it is where Step 3 continues.

Step 3 — Give the guest user access to the two REDA Connect endpoints

Incoming messages arrive as the Site's guest user — an automatic, unlicensed user Salesforce creates for every Site. Out of the box this user can access nothing. It needs permission to run exactly two REDA Connect endpoint classes — and nothing else. No object permissions, no field permissions, no extra permission sets: REDA Connect is designed so that the guest user only hands the message over; all processing happens afterwards in Salesforce's own secure system context.

  1. On the Site's detail page, click Public Access Settings. This opens the Site's guest user profile.
  2. Find the Enabled Apex Class Access section (use the section links at the top of the page, or scroll), and click Edit.
  3. In the Available Apex Classes list, select these two classes and move them to Enabled Apex Classes with the Add arrow:
    • rconn.WAPP_Inbound
    • rconn.TWILIO_Inbound
  4. Click Save.

Expected result: Enabled Apex Class Access lists exactly those two classes.

The Site guest user profile "REDA Connect Profile" open at Apex Class Access, listing exactly two enabled classes: rconn.TWILIO_Inbound and rconn.WAPP_Inbound
The guest user profile after Step 3 — exactly the two REDA Connect endpoint classes are enabled, and nothing else. (Shown in the enhanced profile view, where the section is called Apex Class Access; in the standard profile view the same list appears under Enabled Apex Class Access.)
Do not grant anything else. If a message elsewhere ever suggests giving the guest user object or field permissions to "fix" incoming messages, don't — the guest user doesn't need them, and a public guest user with data access is a security risk. Incoming-message problems are almost always webhook configuration, not guest permissions — see An incoming message didn't arrive.

Step 4 — Write down your two webhook addresses

Your webhook addresses are built from the Site URL (Step 2) plus a fixed path. If you left Default Web Address blank:

WhatsApp:  https://<your-site-domain>/services/apexrest/rconn/wapp-inbound/
SMS:       https://<your-site-domain>/services/apexrest/rconn/twilio-inbound/

If you entered a path suffix (for example reda), it goes right after the domain:

WhatsApp:  https://<your-site-domain>/reda/services/apexrest/rconn/wapp-inbound/
SMS:       https://<your-site-domain>/reda/services/apexrest/rconn/twilio-inbound/

Both addresses must keep the trailing slash — the SMS address in particular is used as a prefix that REDA Connect extends per message, and without the final / delivery receipts will not be recognised.

Worked example

Suppose you registered the domain acmerentals and created the Site with the path suffix reda. Your Site URL shows as https://acmerentals.my.salesforce-sites.com/reda, so:

  • into Meta (later, in Connecting the WhatsApp webhook) you will paste: https://acmerentals.my.salesforce-sites.com/reda/services/apexrest/rconn/wapp-inbound/
  • into Twilio (later, in Connecting the Twilio webhooks) you will paste: https://acmerentals.my.salesforce-sites.com/reda/services/apexrest/rconn/twilio-inbound/

Troubleshooting

SymptomCauseFix
The webhook address shows an "Authorization Required" page in a browserThe two classes aren't enabled for the guest user, or the Site is inactiveRepeat Step 3; confirm Active is ticked on the Site
Meta refuses to verify the webhookWrong verify token, not the Site (covered in the WhatsApp webhook article)Continue setup — verification is checked in Connecting the WhatsApp webhook
"You can't create a Site" or the New button is missingSites not available in your edition, or no Sites domain registeredComplete Step 1; Sites are available in Enterprise, Performance, Unlimited and Developer editions
Delivery receipts (Sent/Delivered) never update on SMSThe SMS webhook address was saved without the trailing slashRe-enter it ending in / — see Step 4

FAQ

The address accepts messages only for the two REDA Connect endpoints, and the guest user it runs as has no access to your data — it can only hand the incoming message to REDA Connect for processing. This is the same pattern any Salesforce-native messaging product uses.

Yes. Open the existing Site's Public Access Settings and complete Step 3 there. Your webhook addresses then use that Site's URL and path. Keep in mind that whoever administers that Site now also affects your messaging.

No — one Site serves both. The two channels use different paths on the same address.

An Experience Cloud site can technically expose the same endpoints, but the plain Salesforce Site described here is simpler and is the supported configuration. Use a dedicated Site.

Where to go next