SDKs

Use an SDK to send database requests from your application. Start with your language, then check its version before copying an example.

1. 01
   Choose your languageOpen the SDK’s source and setup guide.
2. 02
   Check its release instructionsConfirm the version and installation method.
3. 03
   Configure a server-side connectionUse the complete address and token from Connect.
4. 04
   Run a small readInspect the returned result before building a larger workflow.

Choose your languageCopy Anchor Link

The SDKs are available on GitHub. Choose a language for installation instructions and working examples. These guides use the 1.0 source candidate; install it from the linked repository.

The 1.0 source is public, but the new packages are not on registries yet. npm and PyPI still serve earlier APIs; an unversioned install will not install the Client examples in these guides. To use HTTP directly, start with API authentication.

What the candidate supportsCopy Anchor Link

Creating a client connects your application; it does not create tables, generate embeddings or index your text. Prepare the data for the operation you want to call.

Usage and query metrics are also available. Method names follow each language's conventions. Your database must support the operation, and your credential must have permission to use it. Advanced helpers can differ between languages.

Connect to a databaseCopy Anchor Link

Set two server-side environment variables:

The candidate appends operation paths to OC_URL; you do not build a tenant URL yourself. PostgreSQL tools use a separate database login, not these SDK settings. See API authentication for connection availability and credential types.

Read the complete resultCopy Anchor Link

Read a query result in two parts: the returned data and the outcome of the operation.

sql.run returns rows, column metadata, confirmed write counts, nested statement results and the original response. A missing write count means unknown, not zero. A batch can partially succeed; inspect its partial results before repeating any statement.

Full-text results contain hits and optional facets in every search mode. Numeric and date/time strings are preserved rather than silently converted.

Timeouts and retriesCopy Anchor Link

The candidate uses a 60-second default timeout and does not retry requests automatically. Ruby applies that timeout to connection, read and write inactivity. Redirects are not followed.

A timeout, cancellation or 503 can happen after a write commits. Check the outcome before retrying. An idempotency key does not make arbitrary SQL safe to replay. Python and TypeScript retain explicit retry options for existing integrations.

Diagnose a failed requestCopy Anchor Link

Record the SDK version, operation, HTTP status and request ID when available. Keep tokens and private query results out of logs. A protocol error is different from a valid empty result.

Source versionsCopy Anchor Link

Use the candidate README at a verified source commit for setup. Registry releases remain separate; a source update does not publish a package.

Read the API reference · Create your first table · Use the CLI