Kibo Entities API Developer Guide
Understanding Entities in Kibo
In Kibo, “Entities” are a powerful, flexible way to store custom data that doesn’t fit into the standard Kibo objects like Products or Customers. Think of the Entities system as a lightweight, schema-less NoSQL database built directly into the Kibo platform. What makes it different from other platforms is its simplicity and direct integration. Instead of setting up an external database, you can create an Entity List (like a table or collection) and store Entities (like JSON documents or rows) within it. This is ideal for managing data for custom applications, such as a store locator, a blog, product lookbooks, or storing configuration data for an extension.How This Domain Fits Into Kibo
The Entities domain is a foundational service within the Kibo platform that supports custom development. It doesn’t directly interact with core commerce flows like Orders or Carts, but it provides the data backbone for custom features you build on top of them.- Kibo Extensions: An extension might store its settings or metadata in an Entity List.
- Storefront Applications (API Extension): A custom React component on your storefront could fetch data from an Entity List to display store hours, blog posts, or promotional content.
- System Integrations: You can use Entities as a staging area for data being imported from or exported to external systems.
Prerequisites
- Kibo API credentials and basic setup
- Node.js 16+ with TypeScript
- Familiarity with REST APIs and JSON
What You’ll Learn
After completing this guide, you’ll understand:- How Kibo structures custom data using Entity Lists and Entities (based on official API specs).
- The key patterns for creating, retrieving, and managing custom data objects (verified from apidocs.kibocommerce.com).
- Common workflows like creating a custom data store and populating it with information.
- How to avoid the most common beginner mistakes, like formatting the
entityListFullNameincorrectly. - How to read and navigate the official Entity Lists API documentation effectively.
Kibo Entities Fundamentals
How Kibo Organizes Entities Data
The system is straightforward, with two primary data structures:EntityList: This is the container for your custom data. It’s defined by a unique name and a namespace, which together form itsfullName(e.g.,warrantypricing@my-tenant). It holds metadata about the data it contains.Entity: This is an individual data record within anEntityList. It consists of a uniqueidand aitemproperty, which can be any valid JSON object. This schema-less nature is what makes Entities so flexible.
EntityList contains many Entities.
Namespace Architecture
Every Entity List uses a composite identifier in the formatname@namespace:
- Name: The specific data type the list holds (e.g.,
stores,zipcodes,vehicleMakes). - Namespace: The owner or context of the data (e.g., your tenant identifier or application prefix).
fullName (e.g., warrantypricing@12345) is required for all subsequent data operations once the list is created.
Context Scope
When creating a list, you set a contextLevel that controls data visibility:- Tenant: Data is shared across all sites within the tenant (e.g., global reference data like vehicle make/model lookups).
- Site: Data is siloed per site (e.g., site-specific store hours or location-based content).
Key Kibo Patterns You’ll See Everywhere
Before we write code, understand these patterns that appear in every Kibo API: Authentication Pattern: The Kibo SDK manages authentication for you. You create a singleConfiguration object containing your credentials (Client ID, Shared Secret, etc.). This object is then passed to the constructor of specific API clients (e.g., new EntityListsApi(configuration)). The clients will automatically handle the OAuth 2.0 token exchange behind the scenes for every API call.
Request/Response Structure:
When you get a list of entities, Kibo returns a paginated object. The actual data is always inside the items array.
errorCode that tells you exactly what went wrong.
pageSize and startIndex parameters.
API Documentation Reference:
Throughout this guide, we’ll reference specific endpoints. Find complete specs at:
/api-overviews/openapi_entities_overview
Common Entities Workflows
Kibo developers typically work with Entities in these scenarios:- Setting up a new data store: Creating a new
EntityListto hold a specific type of custom data (e.g., a list for “Store Locations”). - Populating data: Adding individual
Entityobjects to anEntityList(e.g., adding each store’s address and hours). - Reading and displaying data: Fetching entities from a list to be used in a custom storefront component or an admin UI.
Schema Definition & Indexing
While Entity Lists accept any JSON structure, you must define Indexes to enable efficient filtering and sorting.The 5-Index Limit
Each Entity List has exactly 5 custom index slots (indexA through indexE), plus the standard _id primary key.
| Slot | Purpose | Behavior |
|---|---|---|
| _id | Primary Key | Always indexed. Unique identifier. |
| indexA – indexE | Custom Filters | Optional. Maps a JSON property to a sortable/filterable column. |
- Data Types: Indexes support
string,integer,decimal,date, andboolean. - Sorting: You can only sort by fields mapped to an index.
- Filtering: Filtering by non-indexed fields triggers a full list scan. Acceptable for small lists (under 2,000 items), but will degrade performance or time out on larger datasets.
Optimization: Natural Keys
To save an index slot, use a meaningful “natural key” as the_id field instead of a generated GUID.
- Inefficient:
_id: "guid-123",email: "user@example.com"— requiresindexAto search by email. - Efficient:
_id: "user@example.com"— allows direct lookup by ID without consuming a custom index slot.
Create an Entity List: The Kibo Way
When You Need This
This is the very first step for storing any custom data. Before you can add individual records (Entities), you must create the container (the Entity List) that will hold them.API Documentation Reference
Endpoint:POST /platform/entitylists
Method: POST
API Docs: Add Entitylist
Understanding the Kibo Approach
Kibo requires everyEntityList to have a name and a namespace, which combine to form a unique fullName like list-name@namespace. This prevents naming collisions and helps organize data, especially in complex environments with multiple applications and tenants. You create the list once, and then you can add, update, or remove entities from it.
Code Structure Walkthrough
Step-by-Step Implementation
Step 1: Setting Up the FoundationfullName already exists), create the list, and return the complete EntityList object, including system-generated properties.
Step 3: The Core Implementation
What Just Happened? (Code Explanation)
- The setup phase created the standard
Configurationobject. - We used an instance of
EntityListsApito interact with the API. - The payload defined the essential properties of our new data container. The
listFullName(e.g.,warrantypricing@12345) is the unique key we will use in all future API calls to interact with this list. - The
createEntityListmethod sent this payload to Kibo, which created the empty list.
Common Beginner Mistakes
Mistake 1: Not understanding theentityListFullName.
You don’t set the fullName directly. Kibo constructs it from the name and namespace you provide. In all subsequent calls (like adding an entity), you must use this full name (e.g., warrantypricing@12345).
Mistake 2: Creating duplicate lists.
The createEntityList call will fail if a list with the same fullName already exists. Your code should anticipate this, either by checking first or by handling the ENTITY_LIST_ALREADY_EXISTS error.
Delete an Entity List
When You Need This: When a list and all of its data are no longer needed. Endpoint:DELETE /platform/entitylists/{entityListFullName}
Warning: This operation is destructive and permanently deletes both the schema definition and all contained data. There is no undo.
Create and Manage Entities
This section covers the core operations for managing the actual data records within a list.Add a New Entity
When You Need This: After creating a list, you need to populate it with data. Each piece of data is a new entity. API Documentation Reference:- Endpoint:
POST /platform/entitylists/{entityListFullName}/entities - Method:
POST - API Docs: Add Entity
Get Entity from a List
When You Need This: When your application needs to read and display the custom data you’ve stored. API Documentation Reference:- Endpoint:
GET /platform/entitylists/{entityListFullName}/entities - Method:
GET - API Docs: Get Entities
Update an Entity
When You Need This: When an existing entity’s data has changed and needs to be replaced. API Documentation Reference:- Endpoint:
PUT /platform/entitylists/{entityListFullName}/entities/{id} - Method:
PUT - API Docs: Update Entity
Important: This is a full replacement of the document. Partial updates (PATCH) are not supported. You must read the existing entity, apply your changes, and rewrite the entire object.
Delete an Entity
When You Need This: When a piece of data is no longer relevant and needs to be removed. API Documentation Reference:- Endpoint:
DELETE /platform/entitylists/{entityListFullName}/entities/{id} - Method:
DELETE - API Docs: Delete Entity
Querying & Filtering Entities
Endpoint:GET /platform/entitylists/{entityListFullName}/entities
Use the filter and sortBy query parameters to retrieve specific records. Fields used in filter or sortBy must be mapped to an index (indexA–indexE, _id, createDate, or updateDate).
Supported Operators by Data Type
| Data Type | Supported Operators | Notes |
|---|---|---|
| String | eq, ne, sw (starts with), cont (contains) | Comparisons are case-insensitive. |
| Integer & Decimal | eq, ne, lt, le, gt, ge | Supports precise matching and range queries. |
| Date | eq, ne, lt, le, gt, ge | Works for custom date indexes and system fields like createDate and updateDate. |
| Boolean | eq, ne | Strict equality matching. |
Note: Thein(list inclusion) andnear(geospatial) operators are not currently supported.
Example Queries
| Scenario | Filter Query |
|---|---|
| Filter by status (string) | indexA eq 'Published' |
| Filter by ID prefix (string) | indexA sw 'PROD-' |
| Filter by price range (decimal) | indexB gt 19.99 and indexB lt 50.00 |
| Filter by creation date | createDate ge 2023-01-01T00:00:00Z |
| Sort by indexed field | ?filter=indexA eq 'active'&sortBy=indexB asc |
Mixed Filtering (Indexed + Non-Indexed)
You can filter on any field within the JSON document, even if it is not explicitly indexed. However, you must include at least one filter on an indexed property to anchor the query. The anchor filter narrows the dataset using the index before the system scans the remaining JSON data. Example: Find items in the “Sales” department (non-indexed) that are also “active” (indexed):Integrating Entities with Other Kibo Domains
Entities + Storefront (Arc.js) Integration
This is the most common use case. An Arc.js application on your product detail page could make a client-side API call to an Entity List to pull in “Lookbook” data or “Buying Guide” content associated with that product. Because the data is schema-less, you can easily adapt it as your content needs change without requiring a developer to alter a database schema.Entities + Extensions Integration
An extension often needs a place to store its configuration. For example, a custom shipping integration might need to store API keys, service URLs, and shipping method mappings. AnEntityList is the perfect place to store this data. The extension can read its configuration from the list upon startup.
Bulk Import Strategy
Entity Lists do not provide a dedicated server-side bulk insert endpoint. High-volume data loading must be orchestrated client-side.Recommended Pattern
- Read source data from your file or external system.
- Split into chunks of 5 records each.
- Process each chunk using parallel async requests (
Promise.allin JavaScript orTask.WhenAllin C#). - Limit concurrency to 3–5 simultaneous requests to avoid
429 Too Many Requestserrors. - Wrap individual calls in try/catch blocks so a single failure does not halt the entire batch.
Best Practices
- Namespace: Always use a unique, identifiable namespace to prevent data collisions with other applications or tenants.
- Index selectively: Only index fields required for sorting or filtering. Avoid indexing fields just because they exist.
- Keep entities lean: Avoid storing large JSON blobs. Smaller documents improve read/write performance.
- Don’t use Entities as a search engine: Entity Lists are not designed for full-text search. For complex keyword matching, use the Kibo Catalog & Search APIs.
- Test schema changes in Sandbox first: Changing index definitions on live data requires re-processing. Validate your schema before deploying to production.
- Plan for the 5,000-record limit: Modifying indexed properties on lists with over 5,000 records will fail with a
VALIDATION_CONFLICTerror. Design your schema carefully upfront.
Troubleshooting Your Entities Implementation
Reading Kibo Error Messages
ENTITY_LIST_ALREADY_EXISTS: You tried to callcreateEntityListwith anameandnamespacethat are already in use.ENTITY_LIST_NOT_FOUND: TheentityListFullNameyou provided in a request does not exist. Check for typos or incorrect formatting.ENTITY_NOT_FOUND: Theidyou provided for a specific entity does not exist in the given list.VALIDATION_ERROR: The request body is malformed, or you are trying to use a filter with invalid syntax.
Common Development Issues
Issue 1: All API calls are failing withENTITY_LIST_NOT_FOUND.
- Why it happens: You are probably formatting the
entityListFullNameparameter incorrectly. It is case-sensitive and must be in the formatlist-name@namespace. A common mistake is to only provide the list name. - How to fix it: When you create the list, save the returned
listFullNameproperty. Use this exact value in all subsequent calls. For example:warrantypricing@12345. - API Reference: All endpoints under
/developer-guides/entitiesrequire this parameter.
- Why it happens: The filter syntax can be tricky, especially for nested JSON. You must use dot notation to access properties within the
itemobject (e.g.,item.address.city). The filter is also case-sensitive. - How to fix it: Double-check your filter syntax against the Kibo documentation. Start with a simple filter (
item.state eq 'TX') and build up to more complex ones. Log the exact data in Kibo to ensure there isn’t a case mismatch (e.g., ‘tx’ vs ‘TX’).
VALIDATION_CONFLICT error when trying to update an Entity List definition.
- Why it happens: The Kibo platform prevents modifications to the
idproperty or any indexed properties on Entity Lists that contain more than 5,000 records. This safeguard prevents timeouts during schema updates on large datasets. - How to fix it: Choose one of these approaches:
- Revert index changes: Ensure your update request does not modify the
idor index configurations — keep them identical to the existing definition. - Reduce list size: Delete items from the list until the count is below 5,000, perform the schema update, then re-populate.
- Create a new list: Create a new Entity List with the desired schema, migrate your data to it, then decommission the old list.
- Revert index changes: Ensure your update request does not modify the

