How to Define an Arc XP Content Source
Now that you’ve seen a generic content source, let’s take a quick look at the special capabilities built into PageBuilder Engine for authenticating specifically against an Arc XP content source.
Special Environment Variables
CONTENT_BASE
Oftentimes, you will have multiple content sources that all share the same base domain. For example, if you are querying Arc XP’s Content API, you may have a domain like https://api.client-name.arcpublishing.com
that many of your content sources share. For this reason, PageBuilder Engine allows you to define special CONTENT_BASE
environment variable that, when present, allows your resolve
function to return a URL “path” rather than a fully qualified URL, and prefixes the CONTENT_BASE
before those paths.
ARC_ACCESS_TOKEN
If you’ve tried to access any of the Arc XP APIs directly, you’ve probably discovered that a simple GET request by itself won’t work. Retrieving data from the Arc APIs requires authentication, most commonly through the use of access tokens. For that reason, PageBuilder PageBuilder Engine provides a special environment variable ARC_ACCESS_TOKEN
reserved specifically for using these access tokens. When used in conjunction with CONTENT_BASE
, this enables content fetching from Arc XP Content API and other sources with as little friction as possible.
Both of these variables will be automatically set for you in deployed sandbox and production environments. However, to get up and running, you’ll need to include them in your local development environment.
Configuring variables for local development
When developing locally, you’ll need to set both variables in your .env
file, as we’ve [seen previously](how-to-use-environment-variables-and—secrets-.html “How To Use Environment Variables and “Secrets"").
These variables should not be stored in your environment secrets, as they should not be deployed.
CONTENT_BASE
will normally look something like this: https://api.sandbox.thepost.arcpublishing.com
, where thepost
is replaced with the name of your organization. This determines which environment (for example, sandbox or production) your local PageBuilder Engine will pull data from.
ARC_ACCESS_TOKEN
will be your personal Arc XP access token, which you can provision by going to Developer Center within Arc XP. Note that this must be generated from the same environment you specified in CONTENT_BASE
. For example, if you use a sandbox CONTENT_BASE
like https://api.sandbox.thepost.arcpublishing.com/
, you should provision your access token from the sandbox version of Developer Center.
Once you have obtained both values, you should add both to your local .env
file. An example file might look like:
CONTENT_BASE=https://api.sandbox.thepost.arcpublishing.comARC_ACCESS_TOKEN=OL1A6U9BPL82SVDPTO6HGP5GUVMUTQR3wltBydEMBqJxkvxsB8ld2RksnP8+AvNKuPHh1ecC
Defining Arc content sources through resolve
Let’s say I have my CONTENT_BASE
environment variable set to the values above, and I want to define a content source for “stories” on the api.client-name.arcpublishing.com
domain. In that case, my resolve
function might look like this:
const resolve = function resolve (query) { const website = query['arc-site'] const requestUri = `/content/v4/stories/?website=${website}&website_url=${query.website_url || query.uri}`
return (query.hasOwnProperty('published')) ? `${requestUri}&published=${query.published}` : requestUri}
As you can see, the requestUri
string that we return in this case is not a fully qualified URL, but instead just a path (denoted by the starting /
character). In this case, PageBuilder Engine will see that this string is not a full URL and will prefix this path with the value of the CONTENT_BASE
variable before making its request - so we don’t have to retype the domain in every content source that shares this domain. On top of that, the ARC_ACCESS_TOKEN
has also been added in the appropriate HTTP header to the request. Once everything is configured, resolve
content sources will Just Work.
There is nothing preventing you from still returning fully qualified URLs from other content sources - using CONTENT_BASE
is purely to keep your code DRY.
Defining Arc XP content sources through fetch
Things are a little different once we get to fetch
content sources. Since fetch
content sources allow you to manage the requests yourself, you must inject CONTENT_BASE
and ARC_ACCESS_TOKEN
at the appropriate places.
You can import the variables into your content source with:
import { CONTENT_BASE, ARC_ACCESS_TOKEN } from 'fusion:environment'
You’ll also need to append CONTENT_SOURCE
to the request URI and attach the ARC_ACCESS_TOKEN
as a bearer authentication token.
import axios from 'axios'import { CONTENT_BASE, ARC_ACCESS_TOKEN } from 'fusion:environment'
// Add other required fields here which are not present aboveconst includedFields = [ 'website_url', 'headlines.basic', 'credits.by', 'display_date'].join()
const fetch = (query) => { const website = query['arc-site'] return axios(`${CONTENT_BASE}/content/v4/search/published?website=${website}&q=*&_sourceInclude=${includedFields}`, { headers: { Authorization: ARC_ACCESS_TOKEN } }).then((content) => { return content }).catch((e) => { // Never return Axios exception object, that may contain sensitive information that can be exposed in the logs throw new Error("API fetch error") })}
export default { fetch, params: {}}
In sandbox, production, and other non-local environments
Special environment variables such as CONTENT_BASE
and ARC_ACCESS_TOKEN
will be set automatically for all deployments in the PageBuilder Deployer. Your content source code will work exactly the same, and no special configuration is necessary.
Handling redirects
If you are using the fetch method implementation in your content sources, you have to handle redirects. See Handling redirects in content sources.
Learn More
For complete details on how access tokens work, see Accessing Arc XP APIs.
For a complete reference on content sources, see the Content Source API Reference.