Skip to content
Review environment of the Cloudprinter Parallel build — fictional data, not the production Cloudprinter service.
Cloudprinter
Sign inStart in sandbox

Changelog

All notable changes to the public APIs of this platform. Dates are UTC. Deprecations are announced here and with Deprecation/Sunset response headers at least 12 months before removal.

2026-10-24 — SDKs 1.1.0 (generated native TypeScript and Python SDKs, CloudCore-compatible client)

Added

  • **Native TypeScript SDK** (sdks/native-ts, @cpp/native-sdk, provisional name) and **native Python SDK** (sdks/native-python, cloudprinter-native-sdk, provisional name), both generated deterministically from GET /v1/openapi.json by scripts/sdk/generate.mjs. One method per operation (createQuote, createOrder, cancelOrderItem, listOrdersAll, …), typed requests and responses, RFC 7807 ProblemError, Idempotency-Key helpers (idempotencyKeyFrom, newIdempotencyKey), cursor-pagination helpers and an X-API-Version MAJOR check (ApiVersionMismatchError). No runtime dependencies (global fetch / Python standard library). SDK versions track the native API version (1.1.0); a unit test fails when the committed output is stale.
  • **CloudCore-compatible TypeScript client** (sdks/cloudcore-compat-ts, @cpp/cloudcore-compat-sdk, provisional name): the exact request shapes of the official cloudcore-nodejs-sdk (orders/add with apikey appended, orders {apikey}, cancel/info/log {apikey, reference}, orders/quote, orders/quote/info, products, products/info) with a **required** baseUrl (the official SDK hard-codes the legacy production host). No vendor code is copied. A differential harness (scripts/sdk/cloudcore-differential.mjs) replays the frozen cloudcore-docs-v1 fixtures through it.
  • Developer portal SDK page shows the three SDKs next to the existing official-SDK and plain-fetch examples.

Known limitations

  • The SDKs are not published to npm/PyPI; consume them from the repository. Package names are provisional.
  • The CloudCore differential harness runs against synthetic, documentation-derived fixtures only: parity with the legacy production API remains unverified (no production captures).

2026-10-24 — Native API v1.1.0 (problem details, per-item cancel, deprecation headers)

Added

  • POST /v1/orders/{id}/items/{itemId}/cancel: cancel one item of an order. Same rules and vocabulary as the whole-order cancel (canceled on the platform, requested while the print partner holds the item and must confirm), idempotent (changed: false on a repeat). The whole-order cancel is unchanged. The credit for a canceled item follows automatically; shipping and tax are credited only once every item is canceled.
  • GET /v1/problems and GET /v1/problems/{code}: catalogue of problem types; the type URI of every problem resolves there.
  • GET /v1/ping: liveness of the /v1 surface.
  • X-API-Version header on every /v1 response.
  • Deprecation mechanism: a deprecated operation answers with Deprecation (RFC 9745, @<unix-seconds>), Sunset (RFC 8594) and Link: <notice>; rel="deprecation", and is marked deprecated: true in /v1/openapi.json (x-deprecations lists them).

Changed

  • **Errors on /v1/* are RFC 7807 / RFC 9457 problem details** with media type application/problem+json: {"type", "title", "status", "detail", "instance", "code", "correlation_id", "errors": [{"field", "message"}]}. The previous {"error": {"code", "message", "field", "correlationId"}} envelope is no longer returned on /v1. code carries the same values as before (e.g. conflict:order_idempotency_conflict); correlation_id equals the X-Correlation-Id header. Rate-limit problems keep Retry-After and X-RateLimit-*. OAuth token endpoints keep the RFC 6749 error format; CloudCore v1.0 is unchanged.

Deprecations

  • <a id="deprecation-example-ping"></a>**Example (not active):** GET /v1/ping is registered as the documented deprecation example (example-ping, sunset 2027-10-31, replacement GET /v1/openapi.json). It is OFF by default and only enabled on test stacks to exercise the mechanism. No production operation is deprecated.

2026-10-23 — Native API v1 (initial review release)

Added

  • Native REST API under /v1: GET /v1/products, GET /v1/products/{reference}, POST /v1/quotes, POST /v1/orders, GET /v1/orders, GET /v1/orders/{id}, POST /v1/orders/{id}/cancel, and webhook endpoint management under /v1/webhook-endpoints.
  • Idempotency-Key header (required) on POST /v1/orders: the same key and body return the original order (HTTP 200, Idempotency-Replayed: true); the same key with a different body returns 409 conflict:order_idempotency_conflict.
  • Cursor pagination on GET /v1/orders (limit up to 100, opaque next_cursor).
  • Structured errors {"error": {"code", "message", "field", "correlationId"}}.
  • OpenAPI 3.1 description at GET /v1/openapi.json.
  • OAuth 2.0 authorization-code flow for connected apps: consent at /oauth/authorize (customer portal), POST /oauth/token (code exchange, refresh rotation), POST /oauth/revoke. Exact redirect URI matching; PKCE S256.
  • Sandbox-only API explorer in the developer portal.

Unchanged

  • CloudCore v1.0 (/cloudcore/1.0/*, JSON body apikey) — existing integrations change only the base URL.

Known limitations

  • CloudApps v2.0 (/cloudapps/2.0/*) routes are not available: the official route inventory could not be verified yet.
  • Store integrations other than the in-repo simulated store are not connected (external dependencies).

Source: apps/public/CHANGELOG.md