• Package: @enadhq/enad-ts-sdk
• Docs channel: latest (0.21.3)
• Version range: >=0.21.0 <0.22.0
• Package reference: TypeScript SDK package reference

The latest track currently describes @enadhq/enad-ts-sdk@0.21.3. Pin that version for reproducible server builds, or use a preserved minor archive when one exists. Confirm exact exports, generated types, method signatures, endpoint fields, and runtime behavior in package or API reference before writing connected code.

Start here for backend, server-runtime, integration, and script usage of the Enad TypeScript SDK.

When to use it

The TypeScript SDK is the package-backed path for Enad clients and generated types in a TypeScript runtime.

Use it for these jobs.

• Backend services, server routes, workers, jobs, scripts, and integration code.
• Package-supported client behavior and generated TypeScript types.
• Search GraphQL calls through @enadhq/enad-ts-sdk/search.
• Codebases that should follow SDK releases instead of maintaining request wrappers by hand.

Before copying imports, constructor options, method names, variables, response fields, or endpoint paths, inspect the reference for the version you are using.

First successful server integration

1. Decide whether the job belongs to an API family, Search GraphQL, or a React storefront surface.
2. Add @enadhq/enad-ts-sdk with your package manager and pin the version for reproducible server builds.
3. Use the root package surface for Enad API client work, or @enadhq/enad-ts-sdk/search for Search GraphQL.
4. Keep private credentials on a server, worker, job, or trusted backend boundary. Do not move private administrative tokens into browser code.
5. Treat credentials, app context, environment, market, store group, locale, and operation-specific context as runtime configuration.
6. Check package, Search, or OpenAPI reference before writing connected code.
7. Validate authentication, tenant/app context, and response shape with the smallest useful operation before building broader workflow code.

Install

Use your project package manager:

pnpm add @enadhq/enad-ts-sdk

For production services, pin the package version rather than relying on a floating range. The latest docs track currently describes @enadhq/enad-ts-sdk@0.21.3; package reference remains the exact published API.

Choose the right surface

TypeScript SDK vs direct API usage

Use the TypeScript SDK when code should rely on package-supported clients, generated types, and versioned package behavior. That is usually the right default for server-side TypeScript projects that already depend on Enad packages.

Use direct API/OpenAPI integration for these cases.

• The endpoint-level contract is the main thing to inspect.
• The integration is not written in a TypeScript runtime.
• You need to verify a method, path, parameter, request body, response schema, auth requirement, or error shape.
• A reference page or raw OpenAPI spec gives a clearer answer than SDK prose.

Use Search GraphQL through the SDK when the job is Search-specific and a package helper or operation document exists. Use Search latest to keep the Search contract, GraphiQL workflow, and React-vs-TypeScript split clear.

Runtime contracts

The core Enad API client uses tuple-style responses:

type ApiResponse<T> = [data: T, error: null] | [data: null, error: ApiError];

Handle error first and treat data as present only when error is null. Keep the exact ApiError shape and method signatures in package reference.

Search is different. @enadhq/enad-ts-sdk/search helpers return data or throw SearchClientError; handle Search calls with try/catch. The Search client needs appId, marketSlug, storeGroupSlug, and locale. Search package exports also include generated documents and generated types for lower-level execution.

Root-package helpers such as product-listing URL helpers, price resolution, stock-signal normalization, and ordered slug lookup belong in package reference. Use this page to choose the helper family, then verify the exact export and return type in the package docs.

For endpoint shape, app-scoped context, GraphiQL workflow, generated-document boundaries, and React-vs-TypeScript Search choices, continue to Search GraphQL latest.

Setup checklist

Before wiring the SDK into a backend or server runtime, confirm:

• Which Enad API family, Search operation, or package surface owns the job?
• Is the code running in a trusted server/runtime boundary rather than the browser?
• Which package version is installed and pinned?
• Which credentials are required, and where are they stored?
• Which app, tenant, market, store group, locale, or environment context is required?
• Does the exact operation have a package helper, a generated Search document, or an OpenAPI reference entry?
• Are generated types and endpoint fields coming from package, Search, or OpenAPI reference rather than prose examples?
• Is there a playground, GraphiQL route, or narrow smoke request that can verify context before broader implementation?

Where to go next

• For API selection, start at APIs.
• For Search-specific work, start at Search latest, then inspect package Search reference for exact usage.
• For shared REST listing query shaping or canonical listing URL handling, start at Product listing helpers.
• For shopper-facing React UI, start at React SDK latest.
• For agent-assisted implementation, load /ai/ts-sdk/latest, Agent files, and /ai/manifest.json.