Connect your CMS

Open Settings → CMS & publishing for your site. Under Where do you publish?, choose your platform and follow its steps. We test every connection before saving it, and keys and tokens are stored encrypted.

A site has one connection at a time: connecting another platform replaces it, and articles already sent stay where they are.

Everything arrives as a draft unless you turn on automatic publishing (how publishing works). All fields per platform are on the integrations page.

Self-hosted WordPress: posts through the REST API with an application password.

1. 1In WordPress, open Users → Profile → Application passwords. Name it “Citable” and click Add.
2. 2Copy the password (24 characters) and paste it in Citable with your site URL and username.
3. 3We test the connection before saving. The password is stored encrypted.

What you need: WordPress 5.6 or later, reachable on the public internet; A user with the Author role or above; An application password for that user.

What gets published: Arrives as a draft. It only goes live if you turn on automatic publishing. To unpublish, switch it to draft in WordPress.

Some hosts strip the Authorization header (Apache without CGIPassAuth). If the test says 401 with the right password, ask your host.

AI visibility for WordPress sites: problems and FAQ

Sites hosted on WordPress.com, on any plan: sign in with WordPress.com and pick the site.

1. 1Click “Connect with WordPress.com”.
2. 2Sign in, choose the site and approve access.
3. 3Back in Citable, we test the connection and show the connected site.

What you need: A WordPress.com account with the Author role or above on the site; Nothing to install: you approve access on WordPress.com and we keep an encrypted token for that site only.

What gets published: Arrives as a draft unless automatic publishing is on. You can unpublish from Citable for 7 days (it goes back to draft).

WordPress.com is not the same as self-hosted WordPress: it uses WordPress.com’s own API and sign-in, so it works on every plan. For WordPress on your own hosting (or WordPress.com Business with plugins), use the WordPress connector with an application password.

If WordPress.com shows “Coming soon”, we’re finishing the app registration with WordPress.com; it appears here as soon as it’s switched on.

AI visibility for WordPress.com sites: problems and FAQ

Items in your CMS collection through the Data API v2, authorised with Webflow.

1. 1Click “Connect Webflow” and authorise the site.
2. 2Choose the blog collection.
3. 3Check the field mapping we suggest and save.

What you need: A Webflow site with a CMS collection for the blog; Permission to authorise apps on that site.

What gets published: Arrives as a draft (staged item) unless automatic publishing is on. You can unpublish from Citable for 7 days.

AI visibility for Webflow sites: problems and FAQ

Items in a Framer CMS collection through the Framer Server API.

1. 1In Framer, open Site settings → General and create an API key.
2. 2Paste the project URL and the key in Citable.
3. 3Choose the collection and check the field mapping.

What you need: A Framer project with a CMS collection; The project URL and an API key (Site settings → General).

What gets published: Arrives as a draft unless automatic publishing is on. You can unpublish from Citable for 7 days.

AI visibility for Framer sites: problems and FAQ

Articles in your store’s blog through the Shopify Admin API.

1. 1In Shopify, go to Settings → Apps → Develop apps and create an app with the write_content scope.
2. 2Install it and copy the Admin API access token.
3. 3Paste your store and the token in Citable, then pick the blog.

What you need: A custom app in your store with the write_content scope; Its Admin API access token (shpat_…); A blog in the store (we let you choose if there are several).

What gets published: Arrives hidden (unpublished) unless automatic publishing is on. To unpublish, hide it in Shopify.

AI visibility for Shopify sites: problems and FAQ

Posts through the Ghost Admin API with a custom integration key.

1. 1In Ghost, open Settings → Integrations → Add custom integration.
2. 2Copy the Admin API key and paste it in Citable with your site URL.
3. 3We test the connection before saving it encrypted.

What you need: Ghost 5 or later; A custom integration and its Admin API key (id:secret).

What gets published: Arrives as a draft unless automatic publishing is on. To unpublish, switch it to draft in Ghost.

AI visibility for Ghost sites: problems and FAQ

Pages in a Notion database, with properties filled in and the article as native blocks.

1. 1In Notion’s developer portal, create an internal connection and copy its installation access token.
2. 2Open your blog database in Notion → ••• → Connections → add the connection.
3. 3Paste the token in Citable and choose the database. We test it and show which properties we’ll fill.

What you need: An internal connection in Notion’s developer portal with read, update and insert content capabilities; The blog database shared with that connection; Recommended: a Status property with Draft and Published options.

What gets published: Arrives as a draft when your database has a Status or Select property (Draft / Published) or a Published checkbox; it’s only set to Published with automatic publishing. You can unpublish from Citable for 7 days. Without a status property, Notion can’t tell a draft from a live page: your site decides.

AI visibility for Notion sites: problems and FAQ

Posts in your Wix Blog, through the Citable app for Wix.

1. 1Click “Install on Wix”, choose your site and approve the app’s permissions (blog, members, media).
2. 2In your Wix dashboard, open Citable (Apps → Manage apps → Open) in this same browser: Wix proves the site is yours and it links in Citable.
3. 3Back in Citable, choose which member signs the articles.

What you need: A Wix site with the Wix Blog app; Being the site’s owner: you install the Citable app and open it from your Wix dashboard, which is how Wix proves the site is yours; A Wix site can be linked to only one Citable site at a time.

What gets published: Arrives as a draft post unless automatic publishing is on. To unpublish, do it in Wix (the API doesn’t offer it).

If Wix shows “Coming soon”, we’re finishing the app registration with Wix; it appears here as soon as it’s switched on.

AI visibility for Wix sites: problems and FAQ

A signed POST to any URL: Zapier, Make, n8n or your own endpoint.

1. 1Paste your receiver’s HTTPS URL.
2. 2We send a signed test (ping) and save it if it answers 2xx.
3. 3Copy the signing secret: it’s shown only once.

What you need: A public HTTPS URL that answers within 10 seconds; Verifying the X-Citable-Signature header with the secret we show once.

What gets published: We send “publicar: false” unless automatic publishing is on; your receiver decides what to do with it and replies with the id (and the URL if it’s live).

Your own blog in Next.js (or any stack): signed webhook or our REST API, with a ready-made example.

1. 1Add the route handler from the example to your Next.js app and deploy it.
2. 2Paste its URL in Citable as a webhook.
3. 3Store the signing secret in your app’s environment (CITABLE_WEBHOOK_SECRET).

What you need: A route in your app that receives a POST and verifies the signature (example below); Or an API key (Developers page) to read articles with GET /api/v1.

What gets published: Same as the webhook: a draft unless automatic publishing is on. Or pull articles yourself from the API v1 when you want.

AI visibility for Next.js sites: problems and FAQ

Posts in your HubSpot blog through the Blog Posts API, authorised with HubSpot.

1. 1Click “Connect with HubSpot”, choose the account and approve access.
2. 2Back in Citable, choose the blog and the author who signs the posts.
3. 3We test the connection; the token is stored encrypted.

What you need: A HubSpot account with Content Hub (a blog); A user who can approve apps for that account; We ask only for the content and files permissions.

What gets published: Arrives as a draft post unless automatic publishing is on (then it’s set to Published, which needs the author you choose here). To unpublish, do it in HubSpot.

This is HubSpot’s blog (CMS). Syncing contacts with the HubSpot CRM is a separate integration.

If HubSpot CMS shows “Coming soon”, we’re finishing the app registration with HubSpot CMS; it appears here as soon as it’s switched on.

Entries of the content type you choose, with your fields mapped, through the Content Management API.

1. 1In Contentful, open Settings → CMA tokens and generate a personal token.
2. 2Paste it in Citable with the space ID (Settings → General settings) and the environment.
3. 3Choose the content type and check the field mapping we suggest.

What you need: A Contentful space and a content type for the blog; A personal access token (CFPAT-…) of a user who can edit and publish in that space; The space ID and the environment (usually master).

What gets published: Arrives as a draft entry unless automatic publishing is on. Changes to a published entry stay pending until you publish them. You can unpublish from Citable for 7 days.

Documents of the type you choose, with the body in Portable Text, through Sanity’s HTTP API.

1. 1In sanity.io/manage, open your project → API → Tokens and add one with the Editor role.
2. 2Paste it in Citable with the project ID and the dataset.
3. 3Choose the document type and check the field mapping.

What you need: A Sanity project, its project ID and the dataset; An API token with the Editor role (write access).

What gets published: Arrives as a draft (a drafts. document, as in Studio) unless automatic publishing is on. If there’s a draft, updates go to it. You can unpublish from Citable for 7 days.

Entries in your Strapi collection (v4 or v5, self-hosted or Cloud) through the REST API.

1. 1In Strapi, open Settings → API Tokens and create a custom token with those permissions.
2. 2Paste your Strapi URL, the version and the token. We check the URL is public before calling it.
3. 3Choose the collection and check the field mapping.

What you need: Strapi 4 or 5 on a public HTTPS URL; An API token (Settings → API Tokens) with create, update and find on the collection, upload, and read access to the Content-Type Builder; Draft & Publish enabled on the collection if you want drafts.

What gets published: Arrives as a draft (Draft & Publish) unless automatic publishing is on. Updates keep the state. To unpublish, do it in Strapi.

Strapi 5 publishes on create unless told otherwise: we always send the draft status explicitly.

Stories with the content-type component you choose, through the Management API.

1. 1In Storyblok, open My account → Personal access tokens and generate one.
2. 2Paste it in Citable with the space ID and region (Settings → Space).
3. 3Choose the component and check the field mapping.

What you need: A Storyblok space and a content-type component for articles; A personal access token (My account → Personal access tokens); The space ID and its region.

What gets published: Arrives as a draft story unless automatic publishing is on. Changes to a published story stay pending until you publish them. You can unpublish from Citable for 7 days.

A copy of the article on Medium, with the canonical link pointing to your site. Only if you already have an integration token.

1. 1On Medium, open Settings → Security and apps → Integration tokens and copy your existing token.
2. 2Paste it in Citable with your blog’s URL.
3. 3We check the token with Medium and save it encrypted.

What you need: A Medium integration token you created before Medium stopped issuing them; Your blog’s URL, where the original article is published.

What gets published: Arrives as a draft unless automatic publishing is on (then it’s public). Medium’s API can’t edit or unpublish: do that on Medium.

Medium no longer issues new integration tokens or allows new integrations; existing tokens keep working. Without one, Medium can’t be connected from any tool. Medium is a copy: publish the original on your site first.

Start a Zap when an article is ready or published: our signed webhook as a Catch Hook, or an instant trigger through our REST API.

1. 1In Zapier, create a Zap with the trigger Webhooks by Zapier → Catch Raw Hook and copy its URL.
2. 2Paste it in Citable as a webhook and copy the signing secret.
3. 3Add a Code by Zapier step to verify X-Citable-Signature (example below), then your actions.

What you need: A Zapier plan with Webhooks by Zapier (it’s a premium app); Or, for the REST hook, an API key with the write scope (Developers page).

What gets published: We send “publicar: false” unless automatic publishing is on: your Zap decides what to do (save it to Google Docs, post to Slack, publish elsewhere…).

Citable doesn’t have a public app in Zapier’s directory. The REST hook endpoints (POST /api/v1/hooks) follow Zapier’s REST Hook pattern, so a private Zapier integration can use them as an instant trigger.

Start a Make scenario with our signed webhook (Custom webhook module) and send the article wherever you want.

1. 1In Make, add Webhooks → Custom webhook, create a webhook and copy its address.
2. 2Paste it in Citable as a webhook; we send a signed test (ping) so Make learns the data structure.
3. 3Verify the signature with a filter or a code module (example below) and answer with Webhook response { "id": … }.

What you need: A Make scenario with the Webhooks → Custom webhook trigger; Turn on “Get request headers” in the webhook to read the signature.

What gets published: We send “publicar: false” unless automatic publishing is on: your scenario decides what to do, and can answer with the id and URL.