When to choose it
- You use a headless CMS — for example a content store behind your own front end.
- You have a bespoke website or an internal portal.
- You want content to go into your own system first, and onwards from there.
- You use WordPress but want publishing routed through an intermediate endpoint of your own.
What do you configure?
| Setting | What it is | Typical value |
|---|---|---|
| Endpoint | The address Pagioo sends content to. | Your system's publishing endpoint |
| Method | The kind of request. | As your target system's documentation says |
| Authentication | How Pagioo identifies itself. | A header token is the most common |
| Field mapping | Which part of the content goes into which field. | title → title, body → content, image → image_url |
| Success condition | What Pagioo treats as a successful publish. | Your system's success response |
Verifying the setup
Send a test
You can trigger a test from the connection settings; it does not use real content.
Read the response
Pagioo shows the target system's answer. Authentication failures, missing required fields and invalid formats all surface here.
Check in the target system
A successful response does not guarantee the content landed in the right fields. Open the record that was created.
Only then schedule real content
A wrong field mapping can create a dozen half-empty records if several pieces go out at once.
What exactly does Pagioo send?
The article's title, body, image reference, metadata and taxonomy data — named according to your field mapping. The test response shows the exact payload.
What happens if the endpoint does not respond?
The publish goes to failed state with the error described, and the content stays in Pagioo. It can be retried after the fix.
Is this the same as the public API?
No. The custom API connection is outbound publishing: Pagioo sends into your system. The public API and webhooks are the opposite: your system queries Pagioo, and Pagioo notifies you of events. That one is on the Scale plan.