Run and inspect
Start from the quick-start commands, in an isolated local environment. Confirm the selected release’s build prerequisites first.
FOR DEVELOPERS
Understand the stack.
Make it your own.
Explicit assemblies. Standard contracts. Your project code. Start with the foundation and add the behavior your application needs.
CHOOSE YOUR STARTING POINT
Three ways into the platform.
Prepare a local run
Integrate through HTTP
Use versioned module paths and the OpenAPI document from your actual deployment. Keep management and public audiences separate.
Extend the assembly
Contribute your own bundles, configuration and content. Analyze and boot-test the combination your project will ship.
DOCUMENTATION
Find your next step.
Getting started
Prepare an isolated local environment and read the launch sequence.
Architecture
Understand the single-process runtime and storage alternatives.
HTTP API
Discover management and public module contracts on your own instance.
Customization
Understand features, project modules and repeatable assemblies.
Security and operations
Review starter defaults and deployment responsibilities.
Page lifecycle
Explore drafts, publication and transactional events as a proposal.
Capability status
Check implementation statements, conflicts and missing verification.
Open-source approach
Understand the Apache 2.0 licensing direction and source publication.
Documentation is not a release certificate.
These guides follow the project documentation snapshot of 18 September 2026. Some documents contain older statements or incomplete verification. The capability-status page records those boundaries instead of turning them into silent assumptions.
For a deployment, use the documentation, build requirements and verification record belonging to the exact release you select. Public source and release links will be connected once they are published and verified.
curl --user YOUR_USER \
http://127.0.0.1:6727/api/identity/v1/meRun against your own local instance. curl prompts for the password; do not commit credentials to scripts. This is a documented endpoint, not an executable demo connected to a public server.
The right contract for the job.
The stock Sling GET/POST surface and the typed Jakarta REST API are separate interfaces. The API gives integrations fixed module routes, typed responses and generated documentation. It does not turn every Sling request into a typed operation.
Public site endpoints belong to a site-enabled deployment and need a configured delivery binding. Do not assume the starter aggregate or a raw localhost host exposes every site capability.
Build against evidence, not assumptions.
Check the current scope
The API is documented as built through step 8. Browser authorization testing and swap continuity still have open verification items.
Separate design from implementation
The page-lifecycle proposal adds transactional extension points. Those proposed Java and HTTP contracts are not current integration targets.
Start small. Understand what you are running.
Read the local setup guide, then follow the architecture and API into your own implementation.