The most important thing about connecting your CMS to AgenticWebTeam is what doesn't happen: no migration, no export, no copy of your content living somewhere new. The assistant works through your platform's official API with credentials you control, your CMS stays the single source of truth, and disconnecting is as simple as revoking a token. This field guide covers how the connection works and what each platform needs — Sanity, Contentful, Webflow and WordPress, plus the rest of the roster.
How every connection works
Three rules apply to all platforms. Credentials are tested live before they're accepted — when you paste a token during setup, we make a real API call to your CMS and only save the connection if it works, so a typo surfaces in seconds rather than at your first task. Everything is stored encrypted (AES-256), entered only in masked fields, and never appears in any chat. And least privilege is the default posture: tokens are scoped to one project, one site, the minimal permissions listed for each platform.
Sanity and Contentful
Sanity needs three things from sanity.io/manage: your project ID, the dataset (usually production), and an API token created under API → Tokens with Editor permission. Sanity is the most fully-featured pairing — published changes are live instantly, drafts of published documents are first-class, and a separate staging dataset can be connected so your team can rehearse changes away from the live site.
Contentful needs the space ID, the environment (usually master) and a Content Management token from Settings → API keys. One behavioural difference worth knowing: on static sites built from Contentful, publishing triggers your site rebuild, so published changes go live in roughly one to two minutes rather than instantly. A staging environment can sit alongside master, same as Sanity's staging dataset.
Webflow and WordPress
Webflow wants a Site API token with CMS read/write scopes, generated under Site settings → Apps & integrations → API access. Webflow stages item changes and publishes them through its normal publish step, which suits its model well — nothing jumps onto the live site unexpectedly.
WordPress uses an Application Password — created under Users → Profile → Application Passwords — never your login password, for a user with Editor or Administrator rights. The assistant then manages posts, pages and media over the REST API. If you run WooCommerce, the same connection extends to products with a REST API key from WooCommerce settings.
The wider roster
Beyond the headline four, the same connection model covers Drupal (via the JSON:API module that's been in core since 8.7), Shopify and Shopify Plus (a custom app token with product and content scopes, managing products, pages and blog articles), BigCommerce (a store-level API account) and Adobe Commerce (an integration access token). Nine platforms, one assistant, one way of working.
One safety rule spans the commerce and WordPress-family platforms: where a published item has no separate draft version, editing live items requires publish permission. Users without it create drafts instead and route changes through the approval workflow — which is exactly the protection you want in front of live, revenue-bearing product content.
Staging, drafts and how platforms differ
The platforms differ most in how they model "not live yet", and the assistant adapts to each. Sanity and Contentful have true draft versions of published documents, which unlocks the richest workflow: edit the draft, preview the diff, publish when approved. Webflow stages item changes behind its own publish step. WordPress, Drupal and the commerce platforms treat published items as live-only — so there, new work happens in fresh drafts, and changing a live item is reserved for roles with publish rights.
None of this requires your team to remember which model they're on. The assistant knows the platform behind the connection and phrases its confirmations accordingly — you'll simply notice it offering a draft-of-published edit on Sanity and proposing a draft-plus-approval route on WordPress. The guardrail travels; only the mechanics underneath change.
Choosing, if you're choosing
Most teams arrive with a CMS already in place, and the right answer is almost always to connect what you have. But if you're genuinely choosing, the pairing guidance is simple. Content-led marketing sites get the most from Sanity or Contentful, where instant APIs, real drafts and staging environments give the assistant its fullest range. WordPress remains the pragmatic choice where the ecosystem matters more than the architecture. And commerce teams should connect the platform that owns their catalogue — Shopify, WooCommerce, BigCommerce or Adobe Commerce — because product content is exactly where careful, permission-gated editing pays for itself.
The honest summary: the assistant meets your stack where it is. The platforms differ in ceremony, not capability — and the workflow your team learns is the same on all nine.
Multi-site organisations should note one structural point: a workspace pairs with one site and its connections, which keeps permissions, billing and audit trails cleanly separated per property. An agency running five client sites runs five workspaces — each with its own roles, its own credentials and its own record of who did what, which is exactly how client work should be partitioned anyway.
Connecting is the easy part
Practically, the connection happens during guided onboarding: pick your platform, follow the credential instructions written for exactly that platform's admin screens, watch the live test pass, done — a few minutes, most of which is finding the right settings page in your CMS. A setup-help chat sits alongside the wizard for the inevitable "where exactly is the token page again?" moments.
After that, the CMS becomes something your team mostly stops thinking about. Content work happens in conversation; the assistant translates it into correct API calls against whatever platform you run; and if you ever migrate platforms, the workflow above the connection doesn't change — which is, quietly, one of the better arguments for keeping your CMS decoupled in the first place.
