CMS integration connects your content management system to the systems around it: commerce, search, digital asset management, CRM, analytics, translation and single sign-on. We build those connections for headless platforms such as Contentful, Strapi, Payload and Sanity, and for traditional ones such as WordPress, Drupal and AEM, so editors stop copying data between tools and every page shows current content.
Integration is often the cheaper first step. If your CMS still suits your editors, connecting it properly may solve the problem you were about to replatform for.
What does CMS integration cover?
Each integration starts with one question: which system owns this data? The CMS should own editorial content. Other systems own prices, stock, assets, leads or user accounts, and the integration decides how that data reaches the page.
| System | What moves | Typical pattern |
|---|---|---|
| Commerce | Products, prices, stock; editorial content for product pages | Product IDs stored in the CMS, live data fetched from commerce at render time |
| Search | Published entries and their fields | Webhook on publish updates the index; a nightly full reindex catches misses |
| DAM | Images, video, rights and expiry data | Asset picker inside the CMS; the CMS stores a reference, not a copy |
| CRM and marketing | Form submissions, consent, gated content access | Frontend posts to the CRM directly; the CMS holds form configuration |
| Translation | Source content out, translated content back | Connector sends changed fields; translations return as draft locales |
| Analytics | Content IDs and types attached to page views | Data layer filled from CMS fields at render time |
| SSO | Editor logins and roles | SAML or OIDC to your identity provider, roles mapped to CMS roles |
For commerce projects this work overlaps with our ecommerce development team, which builds the storefront side.
How content moves between systems
We use three patterns, and most sites need all three.
Webhooks. The CMS sends an HTTP request when an entry is published, changed or deleted. A small service receives it and rebuilds pages, updates the search index or notifies another tool. Webhooks are fast but easy to lose, so we add signature checks, retries, a dead letter queue and logs you can read. Support varies by platform; our list of headless CMS platforms with webhooks compares what each one sends.
Scheduled sync. A job runs every few minutes or every night and pulls changes from one system into another. It is slower than a webhook but recovers on its own after an outage. We use it for bulk data such as product catalogs, and as a safety net behind webhooks.
Render-time queries. The frontend asks the other system directly when it builds or serves a page. This keeps data such as prices and stock always current, at the cost of a dependency on that system’s speed and uptime. We cache these calls and decide per page what happens when the other system is slow.
Keeping preview working
Preview is where integrations usually break. An editor opens a draft product page and sees the new copy, but with yesterday’s price, a missing image or no search results. We build preview against the same integrations as the live site, with draft content from the CMS and live or staging data from the other systems. Editors check one URL and see what visitors will see.
When integration beats replatforming
Replatforming is a large project, and it is not always the answer. Integration is usually the better choice when:
- Editors are happy with the CMS, and the pain is manual work between systems.
- The content model still fits, and you mainly need new data on existing pages.
- A licence or contract keeps you on the current platform for another year or two.
- The site runs on AEM or another enterprise suite that already holds years of approved content. See our AEM development page for that route.
Replatforming wins when the CMS itself is the bottleneck: every copy change needs a developer, upgrades break plugins, or licence cost has grown faster than the site’s value. Our headless CMS development page covers that path and how we pick the new platform.
How we run an integration project
- Map the data. We list each system, the data it owns, who changes it and how fresh it must be on the page.
- Pick a pattern per flow. Webhook, scheduled sync or render-time query, with a fallback for each.
- Build and log. We build the connectors with logging and alerts, so a failed sync shows up in a dashboard and not in a customer complaint.
- Test with editors. Editors publish real content through staging and confirm preview and the live result match.
- Hand over. You get documentation of every flow and the runbook for when one fails.
Proof from a commerce integration
A US-based bootstrapped D2C consumer brand needed editorial content next to its products without a separate CMS to maintain. We rebuilt the storefront on Shopify Hydrogen, kept the Shopify backend and order data intact, and moved landing pages and hero sections into Shopify metaobjects. Editorial time to publish dropped to under an hour, and LCP fell from 4.2s to 1.5s. Read the headless storefront case study.
