How to Integrate Demandbase with Your Headless CMS

What is Demandbase?

Demandbase is an account-based marketing and advertising platform for B2B revenue teams. It identifies companies visiting your site, builds account audiences, runs targeted advertising, tracks intent signals, and connects those signals to sales and marketing workflows. Marketing, demand generation, ABM, and sales teams use it to focus spend and messaging on specific accounts instead of broad anonymous traffic.

Why integrate Demandbase with a headless CMS?

ABM breaks down when your Demandbase audiences and your website content live in separate systems. A marketer might build a target account list in Demandbase, then ask a developer to hard-code a landing page variant for financial services, another for healthcare, and another for manufacturing. Two weeks later, campaign copy changes, the account list changes, and nobody knows which pages, ads, and CTAs are still accurate.

Connecting Demandbase to a headless CMS category tool solves that coordination problem by making account segments, campaign metadata, and page content available through APIs. With Sanity as the AI Content Operating System, content is structured as typed JSON in the Content Lake, so Demandbase-related fields like account tier, industry, buying stage, intent topic, region, and campaign ID can be queried directly. Webhooks can fire on publish, and Functions can push the exact campaign or account-list data Demandbase needs without a polling job.

The alternative is usually a mix of CSV exports, UTM spreadsheets, duplicated landing pages, and manual audience updates inside Demandbase. That can work for one campaign. It gets brittle when you’re running 20 account lists, 6 regions, 4 product lines, and weekly content releases.

Architecture overview

A typical Sanity and Demandbase integration starts when an editor publishes an ABM campaign, landing page, resource, or account-list document in Sanity Studio. The published mutation lands in the Content Lake and triggers either a Sanity webhook or a Function. That server-side handler uses GROQ to fetch only the fields Demandbase needs, such as title, slug, campaign key, Demandbase account list ID, target account domains, industry tags, region, product references, and lifecycle stage. The handler then calls Demandbase's REST APIs with a tenant API token, commonly to update an account list, sync account domains, or attach campaign metadata used by advertising and personalization workflows. On the website, the Demandbase Tag or Identification API can identify the visitor's company and return firmographic attributes like company name, industry, employee range, revenue range, and account segment. Your frontend can use those attributes to query Sanity for the matching content variant, CTA, proof point, or offer. The end user doesn't see the plumbing. They visit a page, Demandbase identifies the account, your frontend asks Sanity for content that matches that account context, and the page renders the most relevant version you’ve approved. The trade-off is that you need a clear data contract between Sanity fields and Demandbase fields. If your teams use different names for the same audience, for example "enterprise_finance" in one system and "finserv_enterprise" in another, fix that first.

Common use cases

Step-by-step integration

1. 1

   Set up Demandbase access

   Create or confirm your Demandbase One account, add the Demandbase Tag to your site directly or through Google Tag Manager, and create an API token from your Demandbase admin settings. Confirm the base API URL and the account-list or audience endpoints available for your tenant, since older Demandbase contracts can expose different API versions.

2. 2

   Model ABM content in Sanity Studio

   Add schema fields that match your Demandbase workflow: demandbaseListId, campaignKey, targetAccounts with domain values, industries, buyingStages, regions, products, and contentVariants. Keep the values controlled with arrays or references so marketers don't type five versions of the same segment name.

3. 3

   Create the publish trigger

   Create a Sanity webhook filtered to published campaign documents, or use a Function if you want the sync logic to run inside Sanity's server-side runtime. Use a GROQ filter such as _type == "abmCampaign" && !(_id in path("drafts.**")) so drafts don't update Demandbase audiences by accident.

4. 4

   Fetch the exact fields with GROQ

   In the handler, use @sanity/client and GROQ to fetch the campaign, referenced products, target account domains, and Demandbase IDs. Don't send the whole document. Demandbase usually needs stable keys, domains, labels, and audience IDs, not Portable Text blocks or internal editor notes.

5. 5

   Call Demandbase's API

   Use the Demandbase REST API with your API token to update the account list, audience, or campaign metadata used by your advertising and personalization setup. Log the Demandbase response ID back to your observability tool, and consider writing the last sync timestamp to Sanity if your editors need visibility.

6. 6

   Test the frontend experience

   Use Demandbase's tag debugger or test domains to confirm account identification. Then test three visitor states: a matched target account, a known company that isn't in the campaign, and anonymous traffic. Each state should render a safe Sanity-authored fallback.

How Sanity + Demandbase works

CMS approaches to Demandbase

Keep building

Explore related integrations to complete your content stack.