Data sources.
The {% collection %} tag reads your site's own data. This page is the catalogue of everything it can read: the source names it accepts, what each one returns, and which sources carry personal data that must never reach a public page.
This page is about the sources. For the syntax, the parameters, paging and the shape of the result, see the collection tag. Read the two together: this catalogue tells you what you can query, that page tells you how.
How a source resolves
The first word after {% collection %} is the source, and sources come in two kinds. A post-type name is an alias: the tag lower-cases it, removes a single trailing "s" and looks the result up in the type list, then queries posts filtered to that type. So blogs means posts of type 2, products means type 3, and pages means type 8. You can ask for more than one type at once by joining names with &, as in {% collection blogs&products %}.
Five names are reserved and are never treated as post types; they query their own tables directly: users, leads, orders, subscriptions and variants. Every other name in the catalogue below is a resource in its own right.
{% comment %} An alias: "blogs" resolves to posts of type 2 {% endcomment %}
{% collection blogs, latest, limit: 5, order: published_at desc %}
{% comment %} A reserved name: queried directly, never mapped to a post type {% endcomment %}
{% collection variants, in_stock, quantity_greater_than: 0 %}The catalogue
Every source {% collection %} accepts is listed here. Names on the same row are equivalent aliases for the same query.
| Source | Returns | Notes |
|---|---|---|
posts, and the post-type aliases (blogs, products, pages, events and the rest) | Content records of the matching type. An alias filters posts to one type. | Public content. Published records only by default; private posts and system types are excluded. |
products, shop_products | Posts of type 3. | Public commerce content, the same records as posts of type 3. |
variants | Product variants. | Public commerce data such as options, price and stock. |
comments | Comments and reviews. | Public. |
files | Media file records. | Public. |
bits | Site bits, the key and value snippets. | Public content. Also present in the context as bits. |
redirects | Redirect rules. | Site configuration. Low sensitivity. |
templates | This site's template records, the Liquid body included. | Your theme source. Readable through the public API as well. |
site | The current site as a single-entry list. | The full site row, the same shape as the site object. |
users, customers, shop_customers | Site users and customers. | Personal data. Privileged, see below. |
orders, api_orders, shop_orders | Order records. | Personal data, including billing and shipping details. Privileged. |
leads | Enquiry and lead submissions. | Personal data. Privileged. |
subscriptions, shop_subscriptions | Subscription records. | Customer billing data. Privileged. |
notifications | Push notification records. | Internal. Scoped by subscription rather than by site, and rarely used in themes. |
Personal data and scope
Every {% collection %} query is scoped to the current site automatically; you cannot read another site's data. Visitor-supplied query-string parameters are filtered so a URL cannot widen a query's visibility, and paging from the URL is clamped. The full rules are on the collection tag page.
What the tag does not do is check the visitor. It runs server-side with your site's own authority, which is why content reads are open but the responsibility for personal data is yours.
Some sources return personal data. Records from users, customers, leads, orders and subscriptions carry names, email addresses, phone numbers and postal addresses. The matching HTTP API endpoints require a manager role for exactly this reason, but {% collection %} is not gated that way. Never render personal fields from these sources into a public page. Use them for server-side logic only, and put your own access checks around anything that exposes them.