SEO blog autopublishing via ApiX-Drive

Implement all four Blogent actions and return their final results. Zapier, Albato and ApiX-Drive require an authenticated callback; accepting a webhook does not confirm publication.

1. Create a Webhook source connection and destination workflow. Use its receiving URL in Blogent and select ApiX-Drive.
2. Branch by action: inventory lists existing native articles and next_cursor; read returns a full snapshot; create/update execute the CMS operation.
3. For writes, call a transactional CMS adapter with persistent operation_id receipts and atomic expected_revision checks. Preserve original target IDs, URLs, dates, authors and assets on update; never blindly upsert by alias.
4. Add Webhooks → Send DATA (Custom) as the final callback step. Keep request_id, callback_url and callback_token through the workflow. Add a final HTTP POST action to callback_url using Authorization: Bearer callback_token and JSON {contract_version:"2.0",request_id,action,result}. Send an explicit failed result on error.
5. Run the connection test. Inventory, creation, authenticated read and update of the same article must all finish. A default webhook acknowledgment or a partial locale result cannot complete the test.

Callback HTTP action documentation

Completion callbacks for queued workflows

1. Select Zapier, Albato or ApiX-Drive in Blogent. Each outgoing action includes an opaque request_id, the exact callback_url and a request-scoped callback_token. Keep these fields through every workflow step.
2. Branch by action. Inventory/read query the native CMS; create/update use the same durable transaction, operation ledger and revision checks as a synchronous connector.
3. After completing the action, POST JSON to the supplied callback URL with header Authorization: Bearer <callback_token>. Body: {contract_version:"2.0",request_id,action,result}. The result has the same shape as that action’s synchronous response.
4. For a failed action, send result:{posted:false,message:"reason",status:409} with the appropriate 4xx/5xx status value. A partial publication must never produce posted:true.
5. Callbacks are bound to the request, action and configuration. Identical repeats are accepted; changed results return 409, invalid tokens 401 and expired callbacks 410. Requests expire after one hour. Blogent may resend the identical request up to five times, at least two minutes apart. Deduplicate by request_id and operation_id.
6. The connection test resumes while callbacks are pending: inventory → create → read → update of the same real article. A queued acknowledgment stays pending. Verification uses the authenticated integration, without crawling public pages.

Actions and stable identities

• Shopify, HubSpot, Webflow and Framer use the connected native publisher. WordPress, OpenCart, Strapi and Lovable use the installed Blogent connector; v0 and Replit adapt it to the existing app. Wix, Make, n8n and custom endpoints implement the synchronous contract; Zapier, Albato and ApiX-Drive use completion callbacks.
• inventory: send cursor: null and limit; return {articles: [snapshot], next_cursor: string|null}. Repeat the returned cursor until null.
• read: send target and/or content_id; return {article_snapshot: snapshot}. Explicit native target is authoritative. Blogent’s logical content_id may differ from the native identity.
• Each snapshot contains identity, title, alias, date, article, target, revision, urls and optional image/author metadata. article maps locales to full title, alias, HTML, preview and SEO fields. Unknown original dates may be null and unavailable URLs may be an empty map.
• create: send the article payload, a unique operation_id, logical content_id, empty target and null expected revision. Return {posted:true,target,revision,urls} after complete publication.
• update: send existing native target IDs and the latest expected_revision. Preserve original IDs, URLs/aliases, publication date, author and assets. Compare the revision atomically before applying changes.

What you get after connecting ApiX-Drive

• Read the existing archive and full native snapshots before planning new articles.
• Update existing native articles while preserving IDs, URLs, original dates, authors and assets.
• Replay identical operations safely and reject stale revisions or changed operation reuse.

Requirements and compatibility

Actions

Implement inventory, read, create and update against the existing CMS and explicit locale mappings.

Concurrency

A transactional adapter with durable operation_id receipts and atomic expected_revision checks; individual no-code upserts are insufficient.

Completion

POST the final result to callback_url using Authorization: Bearer callback_token. Preserve request_id and action.

Frequently asked questions about the ApiX-Drive integration