Using in your app
Destinations can be consumed in the following ways:
- During static site generation.
- At render time using the client’s path.
- With a hard-coded path or destination node ID.
Static site generation
To statically generate an entire site for a destination, first retrieve its sitemap:
The response contains one page of resolved paths and experience URNs:
From here, there are two ways to retrieve each experience:
- Resolve each path through the Destinations Delivery API.
- Extract the experience ID from
experienceUrnand request it from the Experience Delivery API.
These approaches differ in how they use the destination context.
Using the Destinations Delivery API (recommended)
The Destinations Delivery API resolves an experience within its destination context. When an experience is published, its delivery artifacts are updated asynchronously. A destination node tracks which delivery artifacts belong to its linked experience, so resolving through the destination keeps the node and experience artifacts consistent.
Prefer this approach unless measured performance requirements justify bypassing the destination context.
Using the Experience Delivery API
Resolving an experience directly through the Experience Delivery API avoids the destination tree lookup and may reduce latency, but it bypasses the destination context and its consistency guarantees. Consider this tradeoff on a case-by-case basis, and prefer the Destinations Delivery API when possible.
Using the client’s path
Experiences can be resolved at request time, either server-side or client-side, using the client’s path.
For example, a site has the following pages:
The Destinations Delivery API can resolve the experience for the current path:
In a client-side React application, this could look like:
The notable parts of this example are:
- The request reads the path from
window.location.pathnameand sends it to the Destinations Delivery API. The pathname should exactly match a resolved destination node path. - If the response is a redirect, it contains the target path. This example navigates the browser to that path; alternatively, the application can make another Destinations Delivery API request for it.
Hard-coding a path or destination node ID
The final option is to hard-code a path or destination node ID. A hard-coded path uses the same path-resolution endpoint shown above. A stable destination node ID can be preferable to an experience ID for two reasons:
- The upsert operation lets you choose a meaningful, stable destination node ID.
- The destination node can remain the same when its linked experience changes, so the client doesn’t need to be updated when editors replace the experience.
To create a destination experience node with a chosen ID, use the Destinations Management API upsert operation. This operation requires a Contentful management token, which must not be exposed in a client-side application:
Publish the destination node before requesting it from the Destinations Delivery API. Use the version returned by the upsert response, and make sure the destination is also published:
The client can then resolve the experience using the hard-coded destination node ID: