Experience API
The Experience API is the set of Connect REST API resources that expose Experience Cloud site data and capabilities to code, so a custom mobile app, a headless website, or an external service can talk to a site without rendering its pages.
Definition
The Experience API is the set of Connect REST API resources that expose Experience Cloud site data and capabilities to code, so a custom mobile app, a headless website, or an external service can talk to a site without rendering its pages. It is not a separate product. It is the slice of the Connect REST API scoped to Experience Cloud sites, covering the site list, a specific site, publishing, members, feeds, groups, recommendations, and Knowledge articles.
These resources live under the Connect REST API path that starts with /connect/communities, addressed by a site ID or by the site's full URL. The same endpoints that the standard Lightning Web Runtime pages call behind the scenes are available to your own client. Calls run in the context of one site, and most require an authenticated user, though some public Knowledge reads work for guests.
How the Experience API fits inside the Connect REST API
Part of Connect REST API, scoped to one site
The Connect REST API is the Salesforce API for engagement data: feeds, groups, recommendations, files, and the social layer that powers Chatter and Experience Cloud. The Experience API is the part of that API that targets Experience Cloud sites specifically. It is not a different endpoint family with its own authentication. It reuses the Connect REST API URL structure, request style, and JSON responses, then narrows the calls to a single site context. The official docs group these under Experience Cloud Sites resources, and they include the list of sites available to the running user, a specific site by ID, site publishing, and the engagement resources tied to that site. Because it sits inside Connect REST API, anything you already know about that API carries over. You build a resource URL, you authenticate, you read or write data. The shift is that every call now belongs to a site, so a feed read returns that site's feed and a member lookup returns that site's members. This is why teams describe the Experience API as the programmatic side of Experience Cloud rather than a standalone integration product.
Addressing a site by ID or by full site URL
Two addressing styles exist, and picking the right one avoids a lot of confusion. The first uses the org instance plus a community ID: a path that begins /services/data/vXX.0/connect/communities/communityId/ and then names the resource, such as the feed, members, or groups. You get the community ID from the site itself or from the sites list resource. The second style, which the docs call out for OAuth, uses the full path to the site URL. Here you prefix the API path with the site's own base URL, so the request resolves inside the site's domain and its guest or member context. Headless apps lean on the full-URL form because the access token was issued for the site, not the bare org. The version number in the path matters too. Each release adds resources and fields, so an app pinned to an older version will not see newer capabilities until you raise the version. Treat the version as a deliberate choice you test against, not a value you bump blindly in production.
Authentication: members, system users, and guests
Most Experience API calls need an authenticated identity, and you have three common patterns. For an end user, OAuth 2.0 lets a customer's app sign in as that customer, so feed reads and posts happen as the member. For server-to-server work, a Named Credential or the integration user pattern lets a backend service call as a system identity without storing raw credentials in code. The third pattern is the site guest user. When a site exposes content to the public and a Knowledge article is published to the public channel, certain reads succeed without a login, subject to guest user permissions and limits. Getting this wrong is the most common failure. A call that works for a logged-in member returns nothing, or an error, when run as a guest, because the guest user simply cannot see that record. The fix is rarely the API and almost always the sharing, profile, or guest user access settings for the site. Plan the identity for each call before you write it, then confirm the matching permissions exist.
Feeds, groups, and member engagement
The most used Experience API resources are the engagement ones, because they let a custom app reproduce the social parts of a site. Feed resources return a site's feeds, including a home feed and topic or record feeds, and they support posting, commenting, and liking. A branded mobile app can show a member's activity stream without ever loading an Experience Cloud page. Group resources let you list groups, read a group's members, create or delete groups, and add or remove members, which is enough to build a custom group directory or a join flow. Member resources expose the people in the site so you can build a member lookup or a profile screen. Because these run in the site context, they respect the site's roles and sharing, so a partner user sees partner data and a customer user sees customer data. The practical win is that you extend the standard site UI with bespoke features instead of replacing it. Many teams keep the Experience Cloud pages for most of the experience and add one or two API-backed screens where the standard components fall short.
Knowledge and recommendations for help and personalization
Two resource groups make the Experience API useful beyond raw social data. The Knowledge resources surface a site's articles, including trending and top-viewed articles and articles by topic, which is how you build a help center inside a non-Salesforce app or a native mobile screen. When the underlying articles are published to the public channel, guest reads let you serve help content without forcing a login, a common pattern for customer self-service. The recommendation resources expose the site's recommendations, including the ones Einstein can personalize, so a client can fetch suggested content or actions for the current user and render a personalized section. Both groups follow the same site-scoped, version-pinned shape as the rest of the API. The value is consistency: you are not bolting on a separate help or recommendation system, you are reading the same data the standard site already manages, just through code. That keeps content in one place and avoids the duplicate-maintenance trap of hosting the same articles twice.
Headless sites and where GraphQL fits
Headless Experience Cloud is the pattern that pushed the Experience API into the spotlight. In a headless setup, a React or Next.js app runs off platform and renders the entire front end, while the Experience API supplies the data the site would otherwise render itself. The same resources that power the standard Lightning Web Runtime pages can power your own client, so you keep Salesforce as the system of record and own the presentation layer. REST works well for discrete reads and writes, one resource per call. When a screen needs several related things at once, the user's groups plus a recent feed plus their recommendations, the Salesforce GraphQL API can fetch them in a single round trip and ask only for the fields you use. Many headless builds mix the two: Connect REST for the engagement actions it already models cleanly, GraphQL for composite reads. The honest caveat is scope. A fully headless site is a large project with its own auth, hosting, and SEO work. Starting from standard pages and adding API-backed features where they pay off is the lower-risk path for most teams.
Apex access through the ConnectApi namespace
The Experience API is not only an HTTP surface. Salesforce mirrors most Connect REST API resources in Apex through the ConnectApi namespace, so server-side code inside the org can call the same operations without making an outbound HTTP request. Inside an Experience Cloud site, ConnectApi methods run in that site's context, which means a feed or member call returns the site's data the same way the REST resource would. This matters for two reasons. First, it keeps logic on platform when you want a trigger, a queueable job, or a controller to read or post engagement data, with no callout limits or token handling to manage. Second, it gives you a single mental model: the REST resource and the Apex method usually map to each other, so a pattern you prove in one is easy to move to the other. The trade-off is reach. ConnectApi runs inside Salesforce, so an external mobile app or an off-platform front end still uses the REST form. Choose Apex for in-org automation and REST for clients that live outside the org.
How to enable and call the Experience API
The Experience API is not a record you create, it is an API surface you enable access to and then call. The setup work is making sure a site is active, an identity can authenticate, and the resource URL points at the right site and version. Here is the path most teams follow before the first successful request.
- Activate the Experience Cloud site
In Setup, open Digital Experiences (or All Sites) and confirm the target site is active. The Experience API only returns data for a site that exists and is published, so an inactive or never-published site is the first thing to rule out.
- Set up the calling identity
For an external app, create a connected app or external client app and enable the OAuth scopes it needs, then have users sign in through the site. For server-side calls, use a Named Credential or the integration user so secrets stay out of code.
- Build the resource URL for the site
Use either the community ID form, /services/data/vXX.0/connect/communities/communityId/resource, or prefix the API path with the site's full URL for OAuth. Pick a specific API version and keep it consistent across the app.
- Confirm guest or member permissions
If a call should work for the public, check the site guest user's profile and sharing, and publish any Knowledge articles to the public channel. For member calls, confirm the user's profile and the site's sharing expose the data you expect.
The identifier for the Experience Cloud site you are addressing. Read it from the site or from the sites list resource, then place it in the communities path segment.
The vXX.0 segment in the URL. Newer versions expose newer resources and fields, so choose one deliberately and test before raising it.
OAuth for end users, Named Credential or integration user for server-to-server, or the guest user for permitted public reads. Each maps to different visibility.
The site guest user's profile and sharing settings, which decide what an unauthenticated call can see, including public Knowledge.
- A call that works for a logged-in member but returns nothing as a guest is almost always a sharing or guest user permission gap, not an API bug.
- Addressing the bare org instead of the site, or omitting the full site URL with an OAuth token issued for the site, makes calls resolve outside the site context.
- Pinning to an old API version silently hides newer resources and fields until you raise the version and retest.
- Mobile apps generate real API traffic, so watch the org API request limits under Setup as usage grows.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Experience API.
Hands-on resources to go deeper on Experience API.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an Experience API in MuleSoft's API-led approach?
Q2. What are the three layers in API-led connectivity?
Q3. Why use API-led layering?
Discussion
Loading discussion…