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, so deep oneentry/dist/... paths are no longer required.

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 — one import line covers values and types.
'oneentry/types'	You want a types-only module: it carries no runtime code at all, which keeps type-only files (*.d.ts, shared model files, API contracts) free of any value import.

There is no functional difference between them — 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, IProductsEntity } from 'oneentry';

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

const products: IProductsEntity[] | IError = await api.Products.getProducts();

Use import type (or import { type X }) for types: the import is erased at compile time, so it never contributes anything to your bundle.

Deep imports still work

Nothing was removed. Existing code that imports from oneentry/dist/<module>/<module>Interfaces keeps compiling exactly as before — the new entry points are additions, so you can migrate file by file at your own pace.

// 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 end up under both entry points:

Module	Typical types
Products	IProductsEntity, IProductsResponse, IProductsQueryBase, IFilterParams
Pages	IPagesEntity, IPositionBlock, PageType
Blocks	IBlocksEntity, BlockType, IContentSlidesResponse
Orders	IOrderData, IBaseOrdersEntity, IOrderByMarkerEntity, IRefundRequest
Users	IUserEntity, ICartResponse, IWishlistResponse
Forms / FormData	IFormsEntity, IFormAttribute, IBodyPostFormData
AttributesSets	IAttributeSetsEntity, IAttributeSchemaItem
Shared (base/utils)	IError, IConfig, IAttributeValues, IAttributeValue, ILocalizeInfo, LangType

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), and it is available from the root like everything else:

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 Documentation

• Bundle Size & Module Formats - how the SDK is packaged and what actually loads
• Get Started - installation and configuration

---