Documentation
The docs surface is written for people who need to understand the system quickly and act with confidence. That includes operators, collaborators, and anyone responsible for shipping or updating the live product.
The goal is not to describe every possible thing. The goal is to make the important things unmissable: how the system is shaped, how it is updated, and how to onboard without guesswork.
Path
/docs
Formats
6
FAQs
3
Reference Notes
Priority
The first job of documentation is orientation. If a new contributor cannot tell how the public pages, docs routes, content store, and AI surfaces relate to each other, the docs are already late.
That is why the docs begin with structure instead of trivia.
Use Case
People doing live work need a dependable sequence. Which file owns the content model? How do page changes reach the live store? What should be verified after publish?
Those are checklist questions, and the docs are written with that operating reality in mind.
Rule
Documentation drifts when it is written as an afterthought. We keep the examples close to the actual live routes and publishing path so the reference stays grounded.
That makes the docs more useful and less ornamental.
Reference Lens
Docs Chapter 01
01
The live product is made of public pages, AI routes, documentation routes, an editable page store, and the publishing scripts that synchronize defaults into the live database. Understanding that structure makes every later task easier.
Without that shared model, edits feel random and verification becomes guesswork.
Docs Chapter 02
02
A strong publishing system does not depend on someone remembering which hidden string to update. It gives the team a clear source model, a synchronization step, and a verification routine after release.
That turns content changes into an operating discipline instead of a risky improvisation.
Docs Chapter 03
03
A new contributor does not just need access. They need a map: what the system is for, where the source of truth lives, how changes move, and how to verify that the result is correct.
The onboarding docs here are written to provide that map quickly and without dependence on internal folklore.
Onboarding Path
Step 01
Start with how the product is organized before changing any route, copy, or content payload.
Step 02
Understand how source content becomes live content and what is expected after the synchronization step completes.
Step 03
Confirm the public docs, AI streaming routes, and page update flows all behave the way the written docs claim they do.
Step 04
Use the same docs library to bring the next collaborator in so the shared mental model stays intact.
Docs Library
Article
System structureA guided explanation of how the public pages, docs routes, content store, and live publishing flow fit together.
Article
Content operationsA practical guide to editing source content, syncing the page store, and verifying the live result without guesswork.
Article
Contributor rampA first-week path for new contributors who need to understand the system quickly and make safe changes with confidence.
Reference
API referencePractical examples for chat streaming, event replay, and admin page updates based on the live route shape of the product.
Live examples
Streaming
The public AI route accepts UI messages plus metadata and returns a streamed response. The example below starts a conversation and pins a known streamId so the session can be replayed later.
curl -N https://rafaygen.cloud/api/ai/chat \
-H 'Content-Type: application/json' \
-d '{
"messages": [
{
"id": "msg-user-1",
"role": "user",
"parts": [{ "type": "text", "text": "Give me a launch outline for a public AI workspace." }]
}
],
"metadata": {
"streamId": "docs-demo-stream",
"mode": "rafay-pro",
"provider": "rafaygen",
"model": "auto"
}
}'Replay
Use the replay route to inspect the current stream snapshot, receive prior events after a given sequence number, and keep listening until the session reaches a terminal state.
curl -N 'https://rafaygen.cloud/api/ai/chat/events?streamId=docs-demo-stream&after=0'Admin
Authenticated page updates can be sent directly to the admin route. The body can contain a full content object so the live page store stays synchronized with the structured page model.
curl -X PUT https://rafaygen.cloud/api/admin/pages/home \
-H 'Content-Type: application/json' \
-H 'Cookie: rafay_admin_session=YOUR_SESSION_COOKIE' \
-d '{
"content": {
"heroTitle": "Updated headline from a controlled publish",
"heroSubtitle": "This payload can include the full structured page object when needed."
}
}'Reference
If you are new to the system, start with the route shape and content ownership before touching live data. That single step prevents most accidental confusion.
Then read the publishing workflow and the onboarding guide so the update path and the team path stay connected.
Reference
Access is only half the question. The more important question is whether each route and workflow makes permission boundaries explicit enough that the team can work confidently.
The docs keep those boundaries visible so contributors know where public behavior ends and protected behavior begins.
Reference
A publish is not finished when the command returns. It is finished when the public route, the expected content, and any critical interactive behavior all match the intended change.
That verification habit is what keeps docs and product truth aligned.
Support
Start with the Product Operating Model article, then read the Publishing Workflow, then the Team Onboarding guide. That order mirrors how the system is actually meant to be understood.
Yes. The examples on this page are written from the active public and admin route structure so they stay practical instead of decorative.
Whenever possible, no. The strongest pattern is to update the docs alongside the route or content change so the written reference does not drift from the live product.
Reference path
That sequence mirrors how the system is actually meant to be understood: first the shape, then the update path, then the contributor workflow. It keeps docs practical and stops them from becoming a disconnected archive.
The best docs shorten the distance between reading and doing.