Migration guide

Existing GraphQL integrations

Keep /api/graphql during the compatibility window. For new authenticated advanced queries, move to POST /graphql, provide a Developer key with graphql:query, and preserve the same canonical Postgres field semantics. Move common resource discovery to the typed /v1 collection endpoints.

Existing Agent Credit integrations

Map each current action to its v1 typed workflow:

1. Create a short-lived wallet session.
2. Call POST /v1/workflows/prepare with the equivalent discriminated workflowType.
3. Simulate and submit each returned intent through the customer-owned signer.
4. Register each hash with its order and chain ID.
5. Wait for final_success; do not treat mined as product completion.

The compatibility route remains available during Developer Preview. New integrations should not adopt the legacy credential behavior; use validated Developer credentials and typed v1 workflows.

Compatibility rules

REST breaking changes receive a new path major. SDKs use SemVer. Event envelopes declare a schema version. Additive fields may appear within a major, so clients should ignore unknown response fields.

SDK prereleases

The checked-in JavaScript packages are 0.1.0-private-preview.1. Treat that as a prerelease integration contract, not a production-stability promise. Pin exactly the approved version, run your sandbox regression suite, then read the generated SDK metadata and changelog before moving to another prerelease. Do not depend on latest or infer a public registry release for Python, JVM, or Swift packages.

When a workflow type changes, recompile TypeScript and regenerate any OpenAPI client before deployment. Re-run the full canonical sequence: prepare, simulate, submit from your signer, register, wait for final_success, then read the affected resource back from Torq.