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.