Official SDKs
Official SDKs are Acceso-maintained client libraries for the REST APIs.
They keep strict parity with the API surface. They avoid hidden behavior. They optimize for production safety.
What you get with an official SDK
Across languages, official SDKs aim to provide:
A consistent request/response model over HTTP.
Safe defaults for timeouts and retries.
Structured, typed error handling.
Memory-bounded pagination helpers.
Explicit configuration. No hidden global state.
Supported runtimes
Acceso maintains officially supported SDKs for widely used languages and runtimes. They follow the same behavior rules across languages.
JavaScript / TypeScript
The JavaScript SDK is designed for Node.js and modern browser environments. It provides typed interfaces and async-first APIs.
What to expect:
Use it when you want typed models and async-first calls. It fits Node services, tools, and read-heavy frontends.
Promise-based APIs.
Strong TypeScript typings for requests and responses.
Configurable timeouts and retries.
Helpers for batching and pagination where supported.
Operational notes:
Use short timeouts for interactive paths.
Treat retries as “at least once”.
Avoid side effects unless the endpoint is idempotent.
Python
What to expect:
Use it for scripts, services, and notebook workflows. It fits automation and analytics pipelines.
Sync and async clients.
Exception-based error handling.
Pagination helpers that keep memory bounded.
Explicit configuration. No hidden global state.
Operational notes:
Use sync for jobs and CLIs. Use async for high concurrency.
Handle errors by type, not by string matching.
Keep page sizes conservative for large backfills.
Configuration model
Each SDK exposes the same core knobs. Names differ slightly per language.
Core configuration includes:
API key and auth strategy.
Base URL / API host.
Timeouts (connect and total).
Retry policy (max attempts, backoff, jitter).
Default headers (user-agent, tracing, correlation IDs).
Optional logging hooks.
Optional custom HTTP transport configuration.
Typical retry triggers:
SDK retries are designed to be safe by default. They target transient failures.
Retry behavior
Network timeouts and connection resets.
429 throttling responses.
5xx service errors.
Guidelines:
Retries are correct for reads.
Retries can duplicate writes.
Use idempotency where the API supports it.
Pagination behavior
Pagination helpers should:
Keep ordering stable across pages.
Expose page size controls.
Surface continuation tokens explicitly.
Prefer streaming iteration over loading all pages in memory.
Official SDKs track the versioned REST API surface. Pin versions in production.
Versioning and upgrades
Patch releases fix bugs.
Minor releases add new endpoints or optional fields.
Major releases can change signatures or defaults.
When to skip the SDK
Use direct REST calls when:
Your runtime is not supported.
You need a custom transport layer.
You want full control over retries and serialization.
Last updated