Make the first request deliberately
Choose an operation, create the credential type and scope it declares, use the documented base URL and versioned path, validate the response, and retain the request ID.
Developer reference
Build a tenant-safe integration from first request to recovery
Use versioned routes, scoped authentication, strict schemas, typed errors, cursor pagination, replay-safe mutations, signed webhooks, and generated SDK contracts.
Versioned, scoped, and replay-safe
Why RadiantOS
What changes for your MSP.
Read the complete route contract
Every operation identifies method and path, auth scheme, tenant source, region rule, permission, entitlement, request and response schemas, rate limit, idempotency, and audit action.
Recover without duplicating work
Use typed error metadata, retry-after guidance, stable idempotency keys, webhook delivery identities, reconciliation, and dead-letter replay paths.
From signal to proof
Developer reference: a clear operating path.
- Authorize
Use the operation's declared identity
Match the integration to its documented user, portal, agent mTLS, service mTLS, signed-webhook, or public-read contract and grant the least privilege.
- Build
Validate both sides of the exchange
Send only the allowed params, query, headers, and body; parse the strict response or error envelope; preserve request and provider identifiers for reconciliation.
- Operate
Bound retries and prove recovery
Respect rate limits and retryability, prevent duplicate mutations, verify webhook delivery, monitor failures, rotate credentials, and test revocation.
Developer reference
What your team can do.
Copyable read request
curl --request GET '<base_url>/api/v1/<resource>?limit=50' --header 'Authorization: Bearer <access_token>'. Replace each placeholder with the values shown by the operation reference.
Copyable replay-safe mutation
For an operation that requires header-key idempotency: curl --request POST '<base_url>/api/v1/<resource>' --header 'Authorization: Bearer <access_token>' --header 'Idempotency-Key: <unique_key>' --header 'Content-Type: application/json' --data '{"<field>":"<value>"}'.
Authorization and tenant scope
Each operation declares its principal, credential scheme, tenant source, region assertion, RBAC or service grant, ABAC condition, entitlement, and audit action.
Response and error envelope
A denied request is shaped like {"error":{"code":"permission_denied","message":"You do not have permission to perform this action.","request_id":"req_...","route_id":"rmm.command.create","retryable":false,"details":{}}}. Preserve request_id and route_id when troubleshooting.
Pagination, filtering, and sorting
Lists use cursor pagination: ?limit=50&cursor=<cursor>, with items, next_cursor, and has_more in the response. Route allow-lists control filters and sort fields; the default maximum limit is 250 unless an operation declares less.
Webhooks and replay
Receive the raw request, verify signature, timestamp, and source, resolve the tenant from the stored provider mapping, ledger the provider event ID, acknowledge safely, process idempotently, emit audit evidence, and route terminal failures to the dead-letter replay path.
Versioning and SDK contracts
Customer API routes use /api/v1. A breaking change moves to /api/v2, uses a compatibility adapter, or follows an explicit migration window. Deprecations include a replacement route ID, sunset date, migration notes, and usage evidence before removal.
Built for MSP control
Control stays with your MSP.
RadiantOS keeps scope, access, approval, data placement, and audit evidence visible where the decision happens.
Review the security approachTenant and region scope is enforced
Authentication is only the first gate. Every request also passes declared tenant, region, permission, entitlement, schema, rate, replay, and audit checks before domain work runs.
Generated contracts stay aligned
The route and schema catalog generates OpenAPI 3.1 operation references and TypeScript, Go, and Python client contracts; drift and unapproved breaking changes fail the contract gate.
Questions, answered
What MSP teams ask about Developer reference.
Which authentication scheme do I use?
Use the scheme declared by the operation. Customer integrations use the scoped credential path shown in their reference; agents, services, and provider callbacks use their declared mTLS or signature contract.
When can a failed request be retried?
Retry only when the typed error marks the failure retryable. Respect retry_after_seconds, keep the same idempotency key for the same intended mutation, and stop at the documented retry budget.
What should I retain for troubleshooting?
Retain the operation or route ID, request ID, timestamp, HTTP status, retryability, and content-safe integration context. Never log access tokens, webhook secrets, or customer payloads unnecessarily.