Strapi SEO content publishing through the REST API

The Strapi adapter works with the REST collection your site already consumes. It looks up the article by slug, updates the matching document or creates one, and adds a publication timestamp only when the publishing run is allowed to go live.

Best for: Self-hosted or managed Strapi projects with a defined article collection and a frontend that already owns the public blog route.

Support status: stable
Publisher: strapi

How the connection works

Authentication

A Strapi API token and server URL stored outside the browser, plus the API collection name used by the target content type.

Server-side variables

  • SEO_BLOG_PUBLISH_TOKEN
  • SEO_BLOG_SITE_SLUG
  • STRAPI_URL
  • STRAPI_TOKEN
  • STRAPI_COLLECTION
  • SEO_BLOG_SITE_ORIGIN

Publishing sequence

01

Query the collection for an exact matching slug.

02

Map the reviewed body, excerpt, SEO fields, canonical, and image URL.

03

Update the existing document ID or create a new collection entry.

04

Set publication state only for a live run and return the tenant website route.

No-write payload and mapping preview

SEO_BLOG_PUBLISH_TOKEN='<tenant-token>' \
SEO_BLOG_SITE_SLUG='<slug>' \
STRAPI_URL='<strapi-url>' \
STRAPI_TOKEN='<strapi-token>' \
STRAPI_COLLECTION='<strapi-collection>' \
SEO_BLOG_SITE_ORIGIN='<origin>' \
npx --yes @wotaso/seo-blog-admin-cli publish-cms --cms strapi --site-slug '<slug>' --site-origin '<origin>' --dry-run

For a currently due approved post, --dry-run builds the destination payload without writing to the provider. It does not contact the provider or prove credentials, remote schema compatibility, deployment, or a live page; when no post is due, provider inputs are not exercised.

Scheduled runner health heartbeat

SEO_BLOG_PUBLISH_TOKEN='<tenant-token>' \
SEO_BLOG_SITE_SLUG='<slug>' \
STRAPI_URL='<strapi-url>' \
STRAPI_TOKEN='<strapi-token>' \
STRAPI_COLLECTION='<strapi-collection>' \
SEO_BLOG_SITE_ORIGIN='<origin>' \
SEO_BLOG_SCHEDULED='true' \
npx --yes @wotaso/seo-blog-admin-cli health --config seo-blog.config.json --mode cms --site-slug '<slug>' --site-origin '<origin>'

Run this from the real scheduled runner after seo-blog.config.json contains the selected connector configuration and the listed secrets are loaded. It reports configuration readiness, not a live article. The dashboard expires readiness at the returned deadline, with a 36-hour fallback when no deadline is available.

Fields and data model

  • Supports HTML and Markdown body fields
  • Works with documentId or numeric id responses
  • Custom Strapi schemas use an explicit field map

Canonical and route

The frontend connected to Strapi owns the final route, canonical, rendering, sitemap, caching, and deployment. The CMS API response is stored as publishing evidence but is not treated as a separate public copy.

Known limits

  • Collection names and field types differ between Strapi projects.
  • Draft-and-publish behavior depends on the content type configuration.
  • The API token needs both lookup and create or update permission for the collection.

Recovery

  • Use dry run to verify the collection, origin, and field mapping.
  • Check whether the API returns documentId or id before diagnosing an update failure.
  • Resolve schema or permission errors in Strapi and rerun against the same slug.

Integration questions

Where are credentials stored?

The Strapi credentials stay in CI or another server-side secret environment.

Does SEODrafts own the canonical URL?

No. The destination website owns its route, canonical tag, sitemap, rendering, and analytics.

Can the integration be tested before publishing?

Use the no-write payload preview to inspect local mapping, then separately test credentials and the first destination draft before a live run.

Keep the website your team already owns.

Review the opportunity and draft in SEODrafts, then publish approved work through Strapi.

Add my website