Release availability and migration
Choose a verified client version and distinguish it from newer development source.
Reviewed 5 September 2026. The REST contract, hosted docs deployment, npm package, Go/PHP packages, CLI release, and MCP service are separate release surfaces. A merged change does not automatically update them all.
| Surface | Verified public state | Upgrade boundary |
|---|---|---|
| TypeScript | @revkeen/sdk@1.20260822.1541 | Published RevKeenClient, Cart resources, and usage.ingest work with their documented signatures. |
| Regenerated TypeScript | Newer source candidate | Meter/event/provenance methods and newer request options need a tested package release. |
| CLI | @revkeen/cli-binary@0.1.2 | Use the published key-auth/raw API workflow. New login/listen/Cart/TUI commands belong to the candidate guide. |
| Go | Proxy tag v1.20260819.1529 has legacy module identity | Wait for a verified canonical github.com/revkeen/sdk-go tag. |
| PHP | Packagist 1.20260819.1529 exists | Install/auth/error/webhook checks passed; newer contract methods need a release. |
| MCP | Default policy exposes approved read tools | Confirm OAuth and the live tool list for your merchant. |
TypeScript migration
Keep a custom base URL versioned (https://staging-api.revkeen.com/v2) for the published SDK. Use RevKeenClient and the method names shown for your package. Cart uses client.cart.sessionsCreate and client.cart.sessionsConvert; usage ingestion uses client.usage.ingest. Do not rewrite snake_case request fields to camelCase unless the specific request schema declares camelCase.
The release candidate adds named environments, explicit secret/OAuth configuration, per-call request options, typed errors with request/rate-limit metadata, and pagination helpers. Review the candidate's exported types and migration notes before upgrading. Request-option support is not permission to automatically retry a financial mutation: retain a stable caller-owned idempotency key and reconcile uncertain outcomes.
For meters, event retrieval, quantities, and invoice provenance, use the documented REST operation if your installed version has no matching method. API pages label this as HTTP rather than suggesting a nonexistent SDK call. Portal customer operations require a customer bearer session, not a merchant-key client.
Release acceptance checklist
A supported upgrade needs a clean install from the actual package channel, exported-type checks, method/path/body fixtures, authentication and error checks, and raw-body webhook verification. CLI versions/help/checksums must agree across installation channels. MCP needs an authenticated bounded read, not just a health response.
Pin the version you tested, deploy it to staging, and test the workflows your integration uses before production rollout. Monitor SDK release notes and CLI releases.