Throughout these docs we shorten the product name to Castro after the first
mention. The wire protocol keeps that name too: the headers are
X-Castro-* and
the conventional base path is /api/castro. Those are identifiers: don’t
rename them.How it works
You implement a small REST contract on your own backend. When a user clicks Publish, Update or Delete in Castro, our servers push signed HTTPS requests to your endpoints, and your code stores the content wherever your site reads it from.You never poll Castro. Content is pushed to you the moment it’s published,
exactly like a webhook, but with a documented resource contract, so updates,
deletes and page sync work too.
POST {base}/posts, PUT {base}/posts/42, and so on.
What you implement
Only three endpoints are required. Everything else is optional, and unlocked per feature via capabilities: declare what you built, and Castro adapts its UI to match.The two rules that matter most
Everything else is mechanical. These two are where integrations actually break:Sign over the raw body
The HMAC covers the exact bytes Castro sent. Parse the JSON and
re-serialize it to verify, and the signature will match for some payloads and
not others, which looks maddeningly intermittent.
PUT is partial
Apply only the fields present in the body. Castro’s Update Content
action sends nothing but the content. Treat that as a full replace and you
erase the user’s title, categories and SEO.
Get started
Quickstart
Key → three endpoints → connected. About 30 minutes.
Test your implementation
A zero-dependency script that proves your endpoints are correct, before real
content depends on them.
Authentication
API key + HMAC signatures, with verification snippets in three languages.
Troubleshooting
Every failure that actually happens, and the fix for each.