#Article Publisher: Overview
Status: publishing to a site through a module is Available; reading articles through the API (
GET /articles,GET /articles/{id}) is Available; editing, approval, publishing, and generation through the API are Planned. Through the Sapport dashboard, articles are created, approved, and sent to your site by the Bitrix or WordPress module today. The public API for editing and publishing (PATCH,approve,publish), generation (/articles/generation-jobs), and delivery of an article to your system are a design. The FastAPI and Nuxt packages have not been released publicly. No dates are promised.
The article publisher is a pipeline from a topic to a page on your site. The platform selects or accepts a topic, writes an article according to your editorial profile, puts it in the approval queue, and, once you have allowed it, publishes it to your site. If your site is neither Bitrix nor WordPress, the article can be handed off to your system by an event and the API, and you publish it yourself.
#What the pipeline consists of
| Stage | What happens | Where it stands now |
|---|---|---|
| Editorial profile | You describe the niche, audience, tone, and topic sources | Dashboard: Available |
| Generation | AI writes the article from the topic and profile; a paid operation | Dashboard: Available; API: Planned |
| Queue | The article appears in the queue with a status, is edited and approved | Dashboard: Available; reading through the API: Available, editing and approval: Planned |
| Publishing | The article goes to the site through a module or is handed off to you | Modules: Available; handoff: Planned |
#Editorial profile
The profile is a precondition for generation: without it, the platform does not know what to write about or for whom. The profile includes:
| Field | Required | Description |
|---|---|---|
niche | yes | The niche: what your site is about |
audience | no | Who you write for |
tone | no | The tone of the text |
presentation | no | How the material is presented |
topic_sources | no | Where to take topics from: own_site, wordstat, search_console, competitors, manual, urls |
source_urls | no | Addresses to draw on |
avoid | no | What to avoid |
example_text | no | A sample text to model on |
locale | no | The language of the articles |
If the profile is not filled in, a generation request is refused with 409 editorial_profile_required (a code from the error catalog).
#What an article is on the platform
An article has a lifecycle status:
| Status | Meaning |
|---|---|
draft | Draft: just generated or being edited |
review | Under review |
approved | Approved, ready to publish |
published | Published |
transferred | Moved to another place on the platform |
external | Published outside the platform (an external article) |
The internal statuses are shown for understanding. The set and names of statuses in the public API have not been approved in the design (see "Open questions"). The public status "Published" must be confirmed by a real page address, not by a single flag.
#Two ways to get an article onto a site
#Way 1. To the site through a module
This fits if you have Bitrix (module 1.2.1) or WordPress (module 1.1.1). You bind the site with the module, then click "Publish to site via module" in the dashboard. The platform builds a job; the module picks it up on its next poll (every 10 minutes; the hourly heartbeat also tells the module about pending jobs), applies it, and returns the outcome: the page address or the reason for refusal.
For details, the job format, and result codes, see Publishing through modules.
#Way 2. Handing the article off to your system
This fits if you have your own CMS. The platform announces the article.ready event, you fetch the text through the API (GET /articles/{id}, formats html, markdown, blocks), publish it on your side, and report the page address. Until the address is confirmed, the article is considered handed off, not published.
This scheme is Planned; its steps are described in the articles API. In both ways, an article that you edit on your own site is not silently overwritten; see "Versions and conflicts" in Publishing through modules.
#Who can do what
| Action | Minimum permission (dashboard) | Scope (future API) |
|---|---|---|
| View the queue and articles | seo.view | articles:read |
| Edit, approve, publish | seo.manage | articles:write |
| Order generation (paid) | seo.manage | articles:generate |
#What is not part of the public API
Some capabilities work only on the Sapport site itself and are not available to tenants: the platform's own blog, the platform's course pages, the "deep" generation mode. The public API works with your articles and your site.
#Money
Generation is charged to the tenant's wallet. When funds are insufficient, the platform returns 402 insufficient_funds; the spending limit is set per tenant and per integration. By default, no more than 5 paid operations run at once per tenant, and the cost of one operation does not exceed the equivalent of 100 RUB in the wallet's currency (both limits are configurable; when exceeded, 402 spend_limit_reached). The cost of each operation arrives in the usage field. Publishing and editing are free. See Paid operations for details.
#Where next
#Open questions
- Public article statuses (technical). The set of public statuses and how they map to the internal ones (
draft,review,approved,published,transferred,external). - The
handed_offstatus (technical). The design introduces it for publishing "to nowhere" (target: none); it is not in the code yet. - FastAPI and Nuxt packages (for the owner). Whether they will become public.
- Publishing schedule (technical). Today a job always carries
scheduled_at: null; the platform does not pass deferred publishing.