Publishing to Multiple Destinations

Content is one of the most valuable resources in any organization, provided that you can put it to good use. Your ability to publish digital content to the various properties and outputs where it's most needed is a key concern. Let's look at how you can take advantage of Agility CMS for getting your content where it can bring you the most value.

The Promise of Headless

The concept of "Headless" came about mainly due to traditional CMS products that could not publish content outside the website. Traditional, or legacy, CMS locks your content into silos. A Headless CMS (like Agility) allows your content to be accessed anywhere, anytime. We refer to this as Omnichannel Content, where the channels act as the "heads" or outputs for your content. Each channel is responsible for accessing the content from the CMS and displaying it to the user.

Content Delivery APIs

In the headless approach, content is delivered from the CMS to the various channels via APIs. An API is a term for how systems send data to each other. That data is structured based on your Content Architecture and sent using a JSON format, which any modern application can read. The machines, servers, or micro-services that run your various channels (such as websites, apps, email campaigns, etc.) can pull the content from the CMS using the API whenever they need it. There is no limit to how many places you can call the API. Through APIs, you can deliver your content anywhere, anytime.

The Power to Synchronize

With Agility, you can sync your content to multiple locations. It could be sending your content to multiple web servers, build servers, or right to a mobile app. Sync allows you to significantly reduce the risk of network latency or hiccups when accessing content, especially from internal networks or mobile devices.

Pushing Content with Webhooks

Webhooks allow you to trigger actions when content changes, effectively enabling a push mechanism. You can use webhooks to trigger any steps you need, such as rebuilding a particular website page, updating an email template, or updating content in a mobile app.

Automating Your Workflow

Building upon the power of webhooks, you can use tools such as Zapier to automate tasks and actions based on content events. For instance, you could automatically post to social media when content is published. You could automate the translation of your content by triggering an asynchronous workflow that utilizes an external team to do the work, which your team can then approve after receiving a notification.

Telling Content Where It Should Go

Once you're publishing to more than one destination, a practical question comes up for marketing and content teams: how do we know which content goes to which channel, for example the website, app 1, app 2, and so on, and how do we specify that when creating or managing content?

It's a fair question, and the honest answer is that there are several valid ways to handle it. Different organizations do this differently, which is why there is no single "correct" workflow. The best approach depends on how your content models, channels, apps, and internal processes are structured, and on how much of the routing logic you want to live inside Agility versus outside of it.

The four common patterns are:

1. A selector inside Agility — a visible field on the content item where editors choose the destinations.
2. Content structure — using grouped containers, sitemaps, or channels so that where content lives implies where it goes.
3. Development logic and an agreed process — routing rules that live in code, supported by a convention the team follows.
4. An external orchestration layer — a separate system that decides routing when complex personalization, audience, or channel rules are involved.

These approaches are not mutually exclusive. Most teams start with a selector field and add structure as their needs grow. Let's look at each one.

Approach 1: A destination selector inside Agility

This is usually what people are picturing when they ask the question, and it is absolutely possible. Within a piece of content in Agility, you can have a visible tag, checkbox, or selector that shows where that content should be used. The editor creates one resource and chooses whether it should appear on the website, app 1, app 2, or any combination of destinations.

The common way to set this up is to add a field to the relevant content model that lets the content team choose the intended destinations. Depending on how you want it to behave, that field can be:

• a set of Boolean (checkbox) fields, one per destination (for example Show on Website, Show in App),
• a Dropdown List of destination options, or
• a Linked Content field pointing to a small "Destinations" content list, which lets you manage the list of channels centrally and reuse it across models.

To add a simple version in the Agility UI, go to Settings → Models, open the content model you want to tag (or create a new one), click Add Field, and choose the field type that matches the behaviour above. Give it a clear label such as Destinations so it reads well for editors.

From a usability perspective, the content team then has a clear, visual way to say Website only, App only, Website and app, or any specific channel combination, right on the content item.

The other half of the pattern lives on the development side. When the website or app pulls content from Agility, it filters on those selections so each surface only renders what's intended for it. With the Content Fetch API you can filter the list request, and with GraphQL you can do the same in the query:

query AppContent {
  promoArticles(
    filter: { fields_destinations: { contains: "App 1" } }
  ) {
    title
    body
  }
}

Or, fetching a list and filtering in code:

const list = await api.getContentList({ referenceName: "promoarticles", languageCode: "en-us" })

// Only keep items the editor tagged for this surface
const forThisApp = list.items.filter(item =>
  item.fields.destinations?.includes("App 1")
)

The exact filter syntax depends on the field type you chose, but the principle is the same: the editor sets the destinations, and each channel asks the API for only the content tagged for it.

A selector like this earns its place only when a single piece of content genuinely could go to more than one destination, in other words when the destinations are mixed. If a given item only ever belongs to one channel, a selector just adds a decision the editor can get wrong. In that case, separating content structurally is clearer, and that's the next approach.

Approach 2: Let content structure imply the destination

Sometimes the cleanest answer is to not add a flag at all, and instead let the placement of content carry the meaning. When an item always belongs to a single destination, structure removes the routing decision from the editor entirely. Agility gives you a few structural tools for this.

Group containers by destination. Create a set of containers for each destination and group them together, so you have, for example, a group of "Website" containers and a separate group of "App" containers. Because every item inside those containers belongs to that destination by definition, there is nothing for the editor to tag and nothing to get wrong. The grouping itself makes it obvious to the editor where their content will be used, which is often the clearest possible experience. This is the better choice whenever content is not mixed across destinations, and it pairs naturally with a selector field only on the rare models where an item really can span channels.

Use sitemaps and channels. You can manage multiple websites in a single instance using Page Management sitemaps, and use separate channels to keep each surface's content organized. Content on a given sitemap belongs to that site; content in the "App" channel is, by definition, app content.

This works well when your destinations map neatly onto distinct page structures, containers, or feeds. For the patterns involved, see Using Agility CMS for Multiple Sites and Reusing Content across Multiple Web Properties.

Describe the destination with a custom field. Even when the structure already implies the destination, it helps to spell it out for editors. You can add a custom "section" field to the content model whose only job is to describe, in plain language, where the content will appear, for example a short read-only note that reads "Items in this container are published to the mobile app." It drives no filtering and changes no behaviour; it simply documents the intent right where the editor is working. Used alongside container grouping, the structure does the routing and the field does the explaining.

Approach 3: Development logic and an agreed process

In some organizations the routing decision is better expressed in code, supported by a convention the whole team understands. The CMS holds the content; the development layer decides where it surfaces, based on rules that the content and development teams agree on offline. This keeps the editing experience simple and puts the logic where developers can version and test it, at the cost of the routing not being visible inside the content item itself.

Approach 4: An external orchestration layer

When the rules get more complex, for example real personalization, audience segmentation, or channel logic that changes over time, it can make sense to move the decision out of the CMS entirely. In this model Agility is the source of content, and a separate orchestration or personalization layer decides which content goes to which audience on which channel. This is the right call only when the use case genuinely needs it; for most teams, one of the first three approaches is simpler and sufficient.

Choosing an approach

There is no single right answer, and the approaches combine well. A good rule of thumb:

• If a single item genuinely could go to several destinations, use a selector field (Approach 1).
• If each item belongs to just one destination, prefer structure — grouped containers, sitemaps, or channels — and optionally a descriptive field to document it (Approach 2).
• If routing is really a development concern, keep it in code with an agreed process (Approach 3).
• Reach for an orchestration layer (Approach 4) only when personalization or audience rules demand it.

The right setup is something to define during onboarding alongside your chosen integration partner, working through your content structure, channel needs, and publishing workflows so the result is simple and usable for your team.

Unlock More Power with a Content Hub

In addition to publishing and pushing content to multiple channels, you can also bring content into Agility to create a Content Hub. A Content Hub lets you manage content centrally and distribute it to many properties through the Content APIs. Learn more about reusing content across multiple web properties.