How to Integrate AirOps with Your Headless CMS

What is AirOps?

AirOps is an AI workflow platform used by content, SEO, and growth teams to run repeatable workflows for briefs, content refreshes, landing pages, product descriptions, and other marketing operations. Teams build AirOps workflows and apps that combine LLMs, brand guidance, data sources, human review steps, and publishing handoffs. It sits in the AI content workflow category, especially for teams that need consistent outputs at scale rather than one-off prompts.

Why integrate AirOps with a headless CMS?

AirOps works best when the inputs are clean. If your team is pasting article drafts, product fields, category pages, or SEO metadata into a workflow by hand, every run starts with a different format. One editor includes the intro, another forgets the canonical URL, and a third pastes HTML that the workflow wasn't built to read. The result is slower review, less consistent AI output, and a lot of avoidable cleanup.

Connecting AirOps to a headless CMS changes that pattern. Published content can trigger an AirOps workflow automatically, with the exact fields the workflow expects: title, slug, body blocks, author, product references, target keyword, locale, and publish date. With Sanity, that content is structured in the Content Lake as typed JSON, so AirOps doesn't need to scrape HTML or parse page blobs. GROQ selects the precise fields for each workflow, and webhooks fire as soon as content is published, updated, or deleted.

The trade-off is that you need to model the content and workflow inputs carefully up front. A vague “send the whole page” integration is fast to wire together but hard to trust later. A field-mapped integration takes more planning, but it gives you repeatable AirOps runs, cleaner audit trails, and fewer surprises when you scale from 20 articles to 20,000.

Architecture overview

A typical Sanity and AirOps integration starts when an editor publishes or updates a document in Sanity Studio. The mutation lands in the Content Lake, and a Sanity webhook fires with the document ID, type, and operation. From there, you can call a Sanity Function or your own webhook listener. The function uses @sanity/client to fetch the latest published document with GROQ. Instead of sending the entire document, the query can project only the fields AirOps needs, such as title, slug, excerpt, Portable Text body, target keyword, related products, category references, and locale. That field selection matters because most AirOps workflows are designed around named inputs. The function then calls the AirOps public API, commonly by posting to an AirOps app or workflow execution endpoint with your API key, app ID, and mapped inputs. For example, a content refresh workflow might receive the article ID, current title, body text, primary keyword, and URL. AirOps runs the workflow, returns a result or run payload, and your integration can write recommendations back to Sanity, notify an editor, or hand the output to a frontend experience. If the AirOps workflow takes longer than your request timeout, save the run ID and process the result asynchronously.

Common use cases

Step-by-step integration

1. 1

   Set up AirOps access

   Create or choose the AirOps workspace, build the workflow or app you want to run, expose it through the AirOps public API, and create an API key. Note the app or workflow ID, because your webhook handler will use it when it calls AirOps. AirOps can be called over HTTPS from Node 18+ with fetch, so the example below doesn't require a separate AirOps package.

2. 2

   Model the workflow inputs in Sanity Studio

   Add the fields your AirOps workflow expects. For an SEO refresh flow, that might include title, slug, excerpt, body, targetKeyword, seoTitle, seoDescription, primaryCategory, author, locale, and lastReviewedAt. Keep AI output fields separate, such as aiRefreshNotes or aiSuggestedMetaDescription, so editors can review changes before publishing.

3. 3

   Create a publish webhook

   In Sanity, create a webhook that triggers on create and update mutations for the document types you want to send to AirOps. Use a small projection, such as {"documentId": _id, "type": _type, "operation": delta::operation()}, so the handler receives an ID and fetches the latest content itself.

4. 4

   Fetch the exact content with GROQ

   In your Sanity Function, Next.js route, or webhook service, use @sanity/client and GROQ to select only the fields AirOps needs. Join references in the same query, such as categories[]->title and author->name, so the AirOps workflow receives complete context in one request.

5. 5

   Call the AirOps API

   Map the Sanity fields to the AirOps workflow inputs and POST them to the AirOps public API with your bearer token. Keep secrets in environment variables, log the AirOps run ID or response, and retry failed requests with backoff rather than running duplicate workflows.

6. 6

   Test the editorial loop

   Publish a test document, confirm the webhook fires, inspect the payload sent to AirOps, and verify the result. If you're writing AirOps output back to Sanity, use draft fields or review-only fields first so editors approve AI-generated changes before they go live.

How Sanity + AirOps works

CMS approaches to AirOps

Keep building

Explore related integrations to complete your content stack.