Stores

A Store is a low-latency, serve-by-key layer that exposes selected attributes from your warehouse models for direct key lookups. Instead of running a warehouse query at request time, your application reads a Store Entry by its key and gets the attributes back in milliseconds.

Stores are the “what are this user’s values?” surface: give the Stores API a key (for example a user_id) and it returns that key’s current attributes as a JSON object. They are not a sync — a sync moves data to an external destination, whereas a Store is an addressable read layer you query directly.

When to Use a Store

Reach for a Store when a decisioning system needs attribute lookups faster than a warehouse round-trip:

• Web and app personalization — read a visitor’s plan, tier, or last-seen attributes to tailor the experience on page load.
• Edge and serverless functions — enrich a request at the edge without a connection back to the warehouse.
• Ad bidders and real-time decisioning — fetch an audience’s attributes within a tight latency budget.

A Store holds attributes addressed by a key. If you instead need to answer “is this user in an audience?” (a yes/no membership check), that is a separate surface — a Store returns values, not membership.

How Stores Work

A Store is populated from your warehouse and served by key:

1. You point one or more warehouse Models at a named Store and map which columns become Entry fields.
2. On a schedule, the mapped fields are written into the Store as Entries, each keyed by the model row’s index value (id by default).
3. Your application queries the Stores API by key and reads the merged attributes for that key in low-tens-of-milliseconds.

The Store is a cache: the warehouse remains the system of record, and the Store holds a refreshable copy of the attributes you chose to serve.

Entries and Composition

An Entry is a single row in a Store, addressed by its key. An Entry’s shape is defined by the field mapping that populates it. Multiple mappings can compose one Entry — each owns a disjoint set of fields — so the Stores API returns the union of all owned fields as a single JSON object.

Freshness and Deletion

Each Store is refreshed on a schedule, so served attributes reflect the warehouse as of the last refresh rather than live values. When a row leaves the source model, the fields it owned are handled according to the configured deletion behavior:

Setting Up a Store

1. Navigate to Stores in the left sidebar.
2. Click New Store.
3. Enter a Store name (lowercase letters, numbers, and hyphens; must start with a letter).
4. Click Create Store.
5. Open the Store and add a source: select the Model to populate it from.
6. Configure the Field mapping — choose which model columns to write as Entry fields. The index column (id by default) is the Entry key and is not remapped.
7. Set the Deletion behavior and the Schedule (for example, Every 1 hour).
8. Save. The Store populates on its next scheduled refresh.

Prerequisites

• A configured warehouse and at least one Model with an index column (id by default).
• A read:store API key to query the Stores API (issued from the Store detail page).

Querying the Stores API

Read a Store Entry by key using a Bearer API key with the read:store scope.

Endpoint

GET /v1/stores/{store}/entries/id/{value}

Authentication

Pass your read:store API key as a Bearer token:

curl https://composable.zeotap.com/v1/stores/my-store/entries/id/user-123 \
  -H "Authorization: Bearer <your-api-key>"

Response

A 200 OK returns the Entry’s merged fields as a JSON object:

{
  "plan": "pro",
  "tier": "gold",
  "loyalty_points": 4200,
  "first_name": "Alex"
}

Issuing a read:store API Key

1. Open the Store in the UI.
2. Click Issue API key.
3. Copy the key immediately — it is shown only once.

Each key is scoped to read:store and tied to your workspace. Revoke keys from the same page.

Next Steps

• Models — define the warehouse queries that populate a Store.
• Field Mapping — learn how column-to-field mapping works.