Importing types

Every public interface and type of the SDK is re-exported from the package root and from a dedicated oneentry/types entry point. You don't need deep oneentry/dist/... paths.

The short version

// before — deep path into the build output
import type { IAttributeSchemaItem, IAttributeSetsEntity } from 'oneentry/dist/attribute-sets/attributeSetsInterfaces';

// now — either of these
import type { IAttributeSchemaItem, IAttributeSetsEntity } from 'oneentry';
import type { IAttributeSchemaItem, IAttributeSetsEntity } from 'oneentry/types';

Both entry points expose the same set of types: every interface and type of every module, including the shared ones from base/utils (IError, IAttributeValues, ILocalizeInfo, IConfig, …).

Which entry point should I use?

Import from	Use it when
'oneentry'	You already import defineOneEntry (or a helper) from the root, so one import line covers values and types.
'oneentry/types'	You want a types-only module. It has no runtime code, which keeps type-only files (*.d.ts, shared model files, API contracts) free of value imports.

They work the same; pick whichever reads better in your project.

Mixing values and types

The root entry point exports both the runtime API and the types, so a single line is often enough:

import { defineOneEntry } from 'oneentry';
import type { IConfig, IError, IProductsResponse } from 'oneentry';

const config: IConfig = { token: 'your-app-token' };
const api = defineOneEntry('https://your-project.oneentry.cloud', config);

const products: IProductsResponse | IError = await api.Products.getProducts();

Use import type (or import { type X }) for types. The import is erased at compile time, so it adds nothing to your bundle.

Deep imports still work

Imports from oneentry/dist/<module>/<module>Interfaces keep compiling. The root and oneentry/types entry points are additions, so you can migrate file by file.

// still valid
import type { IOrderData } from 'oneentry/dist/orders/ordersInterfaces';

Where do the types come from?

Each SDK module contributes its own interfaces, and all of them are available from both entry points:

Module	Typical types
Products	IProductsEntity, IProductsResponse, IProductsQueryBase, IFilterParams
Pages	IPagesEntity, IPositionBlock, PageType
Blocks	IBlockEntity, BlockType, IBlockSlidesResponse
Orders	IOrderData, IBaseOrdersEntity, IOrderByMarkerEntity, IRefundRequest
Users	IUserEntity, ICartResponse, IWishlistResponse
Forms / FormData	IFormsEntity, IFormAttribute, IBodyPostFormData, IFormsDataFilter, FormDataStatus
AttributesSets	IAttributeSetsEntity, IAttributeSchemaItem
Search	IGlobalSearchResponse, IGlobalSearchGroup, TGlobalSearchEntityType
Shared (base/utils)	IError, IConfig, IAttributeValues, IAttributeValue, IAttributeFile, ITypedAttributeValue, ILocalizeInfo, LangType, IVectorSearchResponse

The full list of a module's types is documented on that module's introduction page.

Checking for errors

IError is the type behind the SDK's default "errors as values" mode (isShell: true). Import it from the root like any other type:

import type { IError } from 'oneentry';

function isErrorResult(result: unknown): result is IError {
  return (
    !!result &&
    typeof result === 'object' &&
    ('statusCode' in result || 'message' in result)
  );
}

const result = await api.Products.getProducts();

if (isErrorResult(result)) {
  console.error('Error:', result.message);
} else {
  console.log('Success:', result);
}

---

Related

• Bundle size and module formats: how the SDK is packaged and what actually loads
• Get started: installation and configuration

---