Getting approved stories out

ErmisAI is not your CMS. Once an editor approves a story, the article has to travel to whatever you actually publish from. This page covers every route that exists, who can use it, and the daily cap that sits in front of all of them.

Nothing leaves before an editor approves it

A story is deliverable only when both of these are true:

• Someone has generated and saved an article for it. A freshly arrived draft holds placeholder text, not an article.
• An editor has approved it on the editorial board, which is the only way a story reaches the Published state.

There is no auto-publish, no scheduled release, and no way to skip approval. See Editorial review and approval for the decisions that get a story there.

The routes that exist

Email delivery appears in the product but is not built. See Email delivery does not exist below.

The daily delivery cap

Every workspace has a limit on how many approved stories are released per day. It is set by your plan and it resets at midnight UTC.

If a subscription goes past due or is canceled, the whole workspace drops to Free limits, including this one. Twenty stories a day, until the invoice is settled.

How you see it

The feed carries three metric cards: Stories, Delivered, and Queued. Delivered is how many stories were released today. Queued is how many approved stories are waiting because the day's allowance is spent; the card turns amber as soon as that number is above zero.

When anything is queued, an amber banner appears above the filters reading {count} queued for delivery (daily cap resets at midnight UTC), with a Manage subscription link straight to the Billing section.

Queued stories are not greyed out in the list — they are removed from it. The Queued card and the banner are the only places they show up. If you open one from a bookmark or a direct link, the story workspace shows Story unavailable with the message Story is currently queued. and a Return to feed link.

What actually counts

• A story counts once, on the day it is first released. Stories released yesterday stay in the feed and do not spend today's allowance.
• The count is a UTC calendar day, not your newsroom's day. For most desks the reset does not land at local midnight — an Athens newsroom sees it at two or three in the morning. Work out what midnight UTC is where you are before you plan around it.
• Raising your plan raises the cap. Queued stories are released the next time the feed is read once the new subscription takes effect.

Pulling stories into your own system

The CMS export is a read endpoint your system calls. ErmisAI never initiates it. This is the route to use for a homegrown publishing pipeline, a static site build, or any CMS that can fetch JSON.

Requirements:

• Plan. Pro, Business Pro, or Enterprise. Plus plans get webhooks but not API keys.
• Role. Only the workspace owner can create keys. Tenant admins and members cannot open the Integrations section at all. (Job titles such as Managing Editor or Reporter are free text and grant nothing.)
• A key. Go to Settings, open Integrations, and use the API keys card. Give the key a label, press Create key, and copy the value straight away — the panel warns that New key values are shown once. Save them before closing this panel. Afterwards you can only see a masked prefix, a Created date, and a Last used date.

Each item your system receives carries the headline, the excerpt, the full article body, the category, tags, reading time, confidence score, the breaking flag, the publication timestamp, the source count, and the source list.

What the export does not include: the sensitive flag, conflict notes, and claim provenance are all review-side signals and none of them are exposed. Whatever editorial checks you rely on have to happen before approval, not downstream.

Hand Public integration API to whoever is writing the integration. It has the request and response contracts, the rate limit, and the live specification document.

WordPress

ErmisAI does not publish into WordPress. Its own connect screen says so: ErmisAI will not publish into WordPress by itself. The plugin only pulls published ErmisAI stories and creates or updates WordPress posts.

There is no Publish to WordPress button anywhere in the product, no category mapping, and no control over WordPress post status. All of that belongs to the connector running inside WordPress.

What the connect flow looks like

The handshake starts in WordPress, not in ErmisAI. A connector redirects the browser to an ErmisAI approval screen headed Connect WordPress, with the deck Approve this site to pull published ErmisAI stories into WordPress posts. It lists the WordPress site, the ErmisAI workspace, the connector version, the WordPress version, and the return URL, and offers Connect site or Cancel.

Approving mints a managed API key and hands it to the connector once. You never see that key value.

Approved sites then appear in Settings under WordPress connections, each showing the site, the Workspace, the Key, when it was Connected, and Last activity. The only control is Revoke access.

The coupling that catches people out

Keys and WordPress connections are two halves of one thing.

• Revoke access on a connection also revokes its key.
• Revoking that key from the API keys card also deletes the WordPress connection. The API keys card gives you no warning that this will happen.
• Reconnecting the same site replaces the previous key automatically and silently. The card states this: Reconnecting the same site replaces the previous managed key automatically instead of leaving stale WordPress credentials behind.

If the plan does not allow it, the connect screen refuses with WordPress sync is not enabled on this plan and WordPress sync is available on Pro, Business Pro, and Enterprise plans. In Settings, the card is replaced with WordPress delivery is unavailable and This workspace plan does not include managed WordPress connections.

Webhooks, honestly

Webhooks are configured in Settings under Webhook configuration: an Endpoint, a Signing secret you supply yourself, and an Enable webhook delivery switch. Send test webhook fires a one-off test.

They are worth setting up if you use monitoring rules and want matches pushed into Slack, a pager, or an internal tool. They are not a story delivery channel. See Alert rules and notifications for what triggers one.

Things to know before you rely on them:

• You must retype the signing secret every time you change the configuration. The form clears the secret box after a save, and the save is refused with Secret is required if you leave it empty.
• The endpoint is only checked properly when a delivery is attempted. A configuration can save cleanly and every delivery afterwards can still fail.
• In production the endpoint must be a public HTTPS address. Internal hostnames, private addresses, and anything resolving to one are rejected. Split-horizon DNS and some enterprise setups will not work.
• There is no retry queue and no re-send button. A failed alert delivery is re-attempted opportunistically on the next monitoring evaluation. A failed test is never retried.
• Send test webhook cannot be driven from a script. It is protected against automated traffic and only works from the browser.

Give Outbound webhooks to whoever is writing the receiver — it has the signature scheme and the exact payloads.

Email delivery does not exist

The Monitoring workspace lists an Email digest channel, and it is honest about the state of it: Email digests are not available yet. Digest-mode rules deliver in-app until email delivery ships. No email is ever sent as a delivery, and the EMAIL tile in the usage breakdown is permanently zero. Alert rules only offer one mode, Instant.

Copying an article out by hand

Every plan can do this, and it always works. Open a story that has a saved article and use the two small buttons in the story workspace: MD, tooltipped Copy markdown, and FMT, tooltipped Copy formatted. They only appear once an article has been generated and saved, and they are not on the feed or the editorial board.

This is not a delivery route. It produces no delivery record, no counter, and no log entry, and it does not touch the daily cap.

Where deliveries are recorded

Reading a webhook failure code

Who can set any of this up

Only the workspace owner. Admins and members do not see the Integrations section, and there is no read-only view of it.

The Integrations section itself only appears on plans that include managed integrations, which starts at Plus. On Free it is not in the settings navigation at all. If billing data cannot be read at that moment, the section disappears and settings shows a warning saying so — that is a temporary condition, not a downgrade.

The settings screen decides what to show from your plan, but every delivery route checks your plan and your payment standing. A past-due Pro workspace therefore still sees the API keys and WordPress cards, while every action behind them is refused until the invoice is settled. See Billing and AI capacity.