Developer portal

Two APIs share one order pipeline:

• Native API v1 — REST with bearer API keys or OAuth access tokens, cursor pagination, an Idempotency-Key header for orders, per-item cancellation and RFC 7807 problem details (application/problem+json, catalogue at /v1/problems). Every response carries X-API-Version. OpenAPI 3.1 at /v1/openapi.json.
• CloudCore v1.0 — the existing JSON API with the apikey in the request body. Existing integrations change only the base URL.

Sandbox credentials

1. Create an account and verify your email. New accounts start in sandbox.
2. In the customer portal, switch the workspace to Sandbox and create an API key under Developer tools. Sandbox keys start with cpk_sandbox_ (native) or cck_sandbox_ (CloudCore).
3. Keep keys server-side. A key is shown once; rotate it if it leaks. Sandbox keys can never see or create live orders, and the API explorer refuses live keys.
4. Give each key only the scopes it needs: catalog:read, quotes:write, orders:read, orders:write, webhooks:manage.

Connected apps (OAuth 2.0)

Apps acting for a customer use the authorization-code flow: send the user to /oauth/authorize on the portal, exchange the code at POST /oauth/token, refresh (tokens rotate) and revoke at POST /oauth/revoke. The redirect_uri must exactly equal a registered URI; PKCE uses S256 only. An access token can never do more than the user who approved it.

The CloudApps v2.0 route inventory (/cloudapps/2.0/*) is not implemented here: the official documentation could not be reached from the build environment, so its routes are not invented.

Versioning

The native API is versioned in the path (/v1). Breaking changes ship as a new version; deprecated endpoints announce Deprecation/Sunset headers and appear in the changelog at least 12 months before removal. The CloudCore v1.0 surface is not force-retired.