Documentation / API
APIs organized around owned resources and visible work.
Rodon APIs should expose stable product concepts rather than leak individual provider protocols. Authentication, tenant context, ownership, and normalized errors belong at the Rodon boundary.
User-facing routes require authenticated identity. Internal gateways use narrow, expiring service grants.
Durable objects carry ownership, timestamps, provenance, permissions, links, and lifecycle state.
Long-running work exposes queued, running, completed, failed, cancellation-requested, and cancelled states.
Uploads and generated artifacts preserve owner and conversation context and pass through configured storage.
Public errors are normalized and correlation-bearing; provider secrets and internal identifiers remain server-side.
How it works
Provider protocols stay behind adapters.
Models, storage systems, sandboxes, and external services evolve independently. Rodon keeps provider-specific credentials and lifecycle differences behind server-owned adapters.
- Clients call Rodon routes rather than third-party execution endpoints.
- Provider identifiers are mapped to canonical Rodon sessions and runs.
- Cancellation is only reported complete when the provider confirms termination.
- Unsupported capabilities appear as explicit degraded states.