Skip to content
All docs

Wix setup

Credential: Account API key

The Wix connector creates draft posts in Wix Blog. They appear under Blog → Drafts for you to review and publish. BirchSeek never publishes them.

Step 1 - create an API key

  1. Go to manage.wix.com/account/api-keys. You must be the account owner — a co-owner’s key is a common cause of blanket 403s.

  2. Create API key, name it BirchSeek, and grant three permissions:

    Permission Why
    Manage Blog Creating and updating draft posts
    Read Blog Finding our own prior post once you have published a draft
    Read Members Resolving the site member a blog post is authored as
  3. Under site access, restrict it to the site you are publishing to.

  4. Copy the key. Wix shows it once.

Read Blog is not optional. Before every publish, BirchSeek looks for the post it wrote last time. If it cannot read published posts, it refuses to publish rather than risk creating a duplicate — so the connection test exercises that permission and fails at setup rather than letting every article fail later.

You also need the Site ID: it is the GUID in your site dashboard URL, right after /dashboard/.

Step 2 - make sure the site has a member

Wix requires a blog post to be owned by a site member. Collaborator ids, contact ids and Wix-user ids are all rejected — only a real member works, and a brand-new site with only Blog installed often has none.

If the connection test reports no members, add one in Wix under Members (or invite yourself), then re-test. BirchSeek deliberately does not create one for you: provisioning a login-capable account on your site is not something a publishing tool should do unasked.

The connection test picks a member, tells you which, and pins it — so every draft is authored by the same person rather than drifting between runs.

Step 3 - send a test

Send a test queries your draft posts, checks the Posts service is readable, and resolves the member. It reports the author as nickname (id). If you have several writers, you can override the member id in the connector form.

What BirchSeek writes

Per article, via POST /blog/v3/draft-posts:

  • title, seoSlug, excerpt (your meta description)
  • richContent — the article converted to Wix’s Ricos rich-content format
  • memberId — the author from step 2
  • seoData.tags — an SEO title, a meta description, and a canonical only when your article’s canonical points at a different host

richContent ends with a ## Sources block: a numbered list pairing each verified claim with the page it was checked against, converted into Ricos with the rest of the article. BirchSeek composes that body once, before any connector sees it, so every connector publishing to your own site writes the same block - there is nothing to append yourself. (A syndicated copy to dev.to, Hashnode or Medium carries the same block, and the canonical link back to your page besides. That copy is not covered by the project setting: those three platforms have no citation field of their own, so the body is the only place the evidence can travel.) The block is on by default, and there is no switch for it in the dashboard: it is a project setting called append_sources_section, and the only way to change it today is PATCH /v1/projects/{id} carrying the whole settings object, because that request replaces the object rather than merging into it.

The top-level publish flag is never sent. That is what makes this a draft connector.

What a refresh run does

This is the one place Wix behaves differently from WordPress or Ghost, and it is worth understanding before it surprises you.

  • If your draft is still a draft, a refresh replaces its content in place. Nothing else changes.
  • If you have already published the draft, a refresh stages the regenerated article as an unpublished revision on the live post. Your live page is untouched, hasUnpublishedChanges flips true in Wix, and you must press Publish in Wix again for the new version to go live.

That is correct draft-first behaviour — nothing goes live without your approval — but it means a green “published” badge in BirchSeek does not mean your live page changed.

Caveats

  • Images and raw HTML in the article body are dropped. Ricos has no equivalent that BirchSeek can write without uploading assets into your Wix media library first, so those blocks are skipped with a warning rather than emitted broken. If an article converts to nothing at all, the publish fails loudly instead of blanking your draft.
  • Wix is slow. A single draft-post create takes roughly 25-30 seconds by Wix’s own documentation. A publishing job occupying a worker for most of a minute is normal here.
  • Size limits. A draft post is capped at 400 KB, a title at 200 characters, an excerpt at 500, a slug at 100. BirchSeek checks these before sending so you get a clear message rather than a Wix 400.
  • Canonical. Wix is your own site, so BirchSeek lets Wix emit its own self-canonical by default and only writes an override when your article’s canonical genuinely lives on another host.

Troubleshooting

  • 403 on everything - work through all five: the key was created by the account owner (not a co-owner), it is scoped to include this site, it has Manage Blog, the Wix Blog app is installed on the site, and the wix-site-id header matches. That checklist is Wix’s own and covers essentially every 403 this connector produces.
  • “cannot read published blog posts” - the key is missing Read Blog. Add it and re-test.
  • Missing post owner information - no member id was sent; re-run the connection test so it resolves one.
  • memberIds … do not exist - the configured member id is not a site member. Clear the field to use the site’s first member.
  • 504 or a timeout - given the 25-30 second create latency this happens; it is retried automatically.