Skip to content
Start free

Integrations · Content API

For a developer-built site, without WordPress or Wix. Your site fetches published posts from a read-only API with the site key, and builds the pages its own way, at the path you choose.

  • One site key, kept on the server
  • List, full post and sitemap, by language
  • Your site keeps its look and its blog address
Publish my 4 free postsSee how it works

No card · 4 posts in total, on 1 site

Step by step

  1. Choose Developer site

    In the portal, under Settings, Connection, choose Developer site and set the blog prefix. If you leave it as is, posts live under /blog.

  2. Generate the site key

    Under Site API keys, generate a key. It starts with bpa_ck_ and is shown in full only once: copy it right away.

  3. Keep it on the server

    Your developer stores the key in a server environment variable and sends it in the x-bpa-api-key header on every read. The site connection test in the portal confirms the key.

  4. Build the pages once

    With the API, your developer builds the post list, the post page and the sitemap entries. After that, every published post shows up on the site through the API itself.

What the API returns

  • GET /me

    The site, the account status, the languages and the blog path.

  • GET /posts?locale=en

    Published posts in that language, newest first: title, description, date, cover, tags, author and reading time. Without the HTML.

  • GET /posts/{locale}/{slug}

    The full post, with the HTML, the cover dimensions and the slug of its versions in other languages, when they exist.

  • GET /sitemap

    Each post’s path, last-modified date and slug in each language, for your site’s sitemap.xml and hreflang.

POST /validate confirms the key. The API only reads: your site doesn’t create or edit posts through it.

Example

The API address is in the portal, next to the key.

# The key lives in a server environment variable
BPA_CONTENT_API_KEY=bpa_ck_…

# Published posts in English
GET /posts?locale=en
x-bpa-api-key: bpa_ck_…

# One full post, with the HTML
GET /posts/en/{slug}
x-bpa-api-key: bpa_ck_…

Limits

  • The API only reads. Creating, editing and approving posts stays in the BlogPost dashboard.
  • Published posts only: a draft or a slug that doesn’t exist returns 404.
  • Google reads your site’s sitemap.xml, not the API. Merge the /sitemap entries with your site’s pages.
  • The key isn’t the portal login: changing the password doesn’t take the blog down. Revoking the key in the portal cuts off reads right away, until the site gets a new key.
  • The post arrives as HTML; the styling is your site’s.

Other integrations

  • WordPress

    Username and application password, no plugin: the WordPress step by step.

  • Wix

    Site ID, member ID and API key: the Wix step by step.

  • All integrations

    WordPress, Wix and the API side by side: what each one needs and what arrives.

  • Pricing

    4 free posts to try it; then US$49/month or US$490/year.

Publish my 4 free posts

No card · 4 posts in total, on 1 site

Questions from developers.

  • No. Your site reads the posts through the content API and builds the pages its own way, without WordPress and without a plugin.

  • No. Keep the key in a server environment variable and make the reads from there. In the browser, any visitor could see the key.

  • The full key isn’t stored in the portal. If it’s still on your site’s server, paste it in the portal to test again; if not, generate another and revoke the old one.

  • Through your site’s sitemap.xml. The /sitemap route returns each post’s path and date; your developer merges those entries with the site’s pages.

  • Each post has one language. The list filters by language, and the post carries the slug of its versions in other languages, when they exist, for hreflang.

BlogPost content API for developer-built sites