---
title: Collection-Content Data Source
slug: experience/collection-content-data-source
docTags: 
createdAt: 2026-05-11T12:27:48.720Z
---

## Overview

The `collection-content` data source fetches the contents of a specific curator collection from the Catalog API. It gives editorial teams direct control over what appears in a list — the items and their order are managed through the Curator tool, not by API filters. This is the correct replacement for the deprecated `collection` type.

## Basic Example

```json
{
  "type": "collection-content",
  "contextKey": "featured",
  "collectionId": "home-featured",
  "batchSize": 10
}
```

This loads the contents of the `home-featured` collection and exposes them as `$context.featured`.

## Configuration

### Type-specific properties

| Property     | Type   | Default | Description                                                                                       |
| ------------ | ------ | ------- | ------------------------------------------------------------------------------------------------- |
| filter       | object | —       | **Required.** Identifies which collection to load                                                 |
| fetchOptions | object | —       | Optional fetch request options (e.g. totalCount: false skips the count query for faster requests) |

### Filter properties

| Filter key | Type         | Description                                    |
| ---------- | ------------ | ---------------------------------------------- |
| id         | StringFilter | Match collections by ID                        |
| name       | StringFilter | Match collections by name                      |
| properties | MapFilter    | Match collections by custom property key/value |

### Common configuration (inherited)

All common data source properties apply — `limit`, `offset`, `batchSize`, `contextKey`, `maxCacheAge`, etc.

For more details, see: [Data Sources Overview](docId\:fuMBUaBWeON_OTO5wfevf)

## Advanced Features

### Dynamic collection ID from context

The `collectionId` can be resolved from context to make a single view definition serve different collections:

```json
{
  "type": "collection-content",
  "contextKey": "items",
  "collectionId": "$context.collection.id"
}
```

For more details on value interpolation, see:
[TODO insert link to Value Interpolation](#)

## Testing Notes / Edge Cases

- **Collection must exist**: If the `collectionId` does not match a published collection in the Catalog API, the data source returns an empty list with no error. Always verify the collection ID matches exactly (case-sensitive).
- **Editor-controlled order**: Unlike `content`, results are returned in the order editors placed them in Curator. `sort` overrides are not applicable. If ordering seems wrong, check the Curator configuration.
- **Empty collection**: An empty collection returns zero items. The UI should have an appropriate empty state.
- `limit`** vs. collection size**: If `limit` is smaller than the number of items in the collection, only the first N items (in Curator order) are shown. This is intentional for "top N featured" patterns.
- **Caching**: Collection contents are cached. After an editor updates a collection in Curator, changes may not appear immediately depending on the `maxCacheAge` setting.
- **Do not use **`randomize` with curated collections — it defeats the editorial ordering.

## Related Topics

- [TODO insert link to Data Sources Overview](#)
- [TODO insert link to Content Data Source](#)
- [TODO insert link to Value Interpolation](#)
- [TODO insert link to Curator documentation](#)