Troubleshooting & failures

A broken embed degrades to a working Webflow page. This page explains exactly how failures behave, the debug tools, and the common gotchas.

Shared setup - the script tag, keys, and data binding - is in the getting started guide.

Behaviour when things fail

Before the first successful response, Webflow's server-rendered items are still on screen — so a missing or unsynced collection, a rate limit, or an offline visitor leaves the page exactly as Webflow published it, with a [slater-search] console warning, rather than blanking it. After a successful load, the last good render stays put. One list failing never affects another on the same page.

A global search block has no server-rendered fallback: if the very first search fails, its container simply stays empty (the idle element remains); after a success, later failures keep the last good results, same as lists. And data-slater-empty never shows on a failed request — "no results" is only ever a true statement about the data.

Failure	What the console says	What visitors see
402 — the site's plan doesn't cover the feature	`…does not cover collection data (402). Upgrade the site's Slater plan to restore this feature.`	The published Webflow page, unchanged. See pricing — plans are managed in the dashboard.
404 — collection	`Collection "x" is not enabled for site …`	The published page. Wrong collection slug, or the collection isn't synced + enabled in Slater.
404 — group	`Group "x" was not found for site …`	The published page. Check the slug in Data → Groups, or the group has no enabled member collections — see multi-collection lists.
429 — rate limited	`rate limited. Keeping the current results.`	The current results; the next interaction retries.
Network / anything else	`… Keeping the last successful render.`	The last good render (or the published page before the first success).

If you're debugging a 402 in the network tab: gated endpoints answer with a machine-readable body —

{
  "error": "This site's Slater plan does not include global search",
  "code": "payment_required",
  "requiredPlan": "search",
  "currentPlan": "data"
}

The Data-level message is This site does not have an active Slater subscription; currentPlan is "none" for a site whose free trial has lapsed.

Server-side warnings — an unknown filter, facet, search or expand field — also surface as console warnings prefixed with the block's key, while the list keeps rendering.

Debug mode

Add ?slater-debug=1 to any page URL — or data-slater-debug to the script tag — to see the detected list, the template node, the resolved endpoint, and the first item's field names in the console.

Symptom → cause

Symptom	Likely cause
Global search does nothing until a couple of characters	By design: `data-slater-min-length` defaults to 2. Set it to 1 to search on the first keystroke.
A search input drives the wrong widget (or none)	With several lists/search blocks on a page, an input outside every wrapper is ambiguous — point it with `data-slater-for="<key>"`.
Search cards link to `%2Fblog%2F…`	You used `data-slater-href="{url}"`; patterns percent-encode placeholders. Use `data-slater-item-href` or `data-slater-bind-href="url"`.
List doesn't change / warning `Collection "x" is not enabled`	Wrong collection slug, or the site/collection isn't synced + enabled in Slater.
Warning `Group "x" was not found`	The `data-slater-group` value doesn't match a group slug in Data → Groups, or the group has no enabled member collections.
A filter returns everything + warning `Unknown filter field "x"`	Using Finsweet's label instead of the real CMS slug. Check `?slater-debug=1`.
Checkbox/radio filter does nothing	The value is on the native `value` attribute (Webflow ignores it) — use `data-slater-value`.
Cards show the wrong image, or text shows `[object Object]`	An old cached bundle. Current builds coerce every field type and remove missing images; see script caching below.
Sort order looks random for numbers	The field is stored as text (commas). Sort a real number/date field instead.
Nothing renders, no warning	No `data-slater-template` found, and no `.w-dyn-item` to fall back to. Open the console with `?slater-debug=1`.

Testing against the dev API

The bundle points at the production API by default. To test against dev, override the endpoint and load the dev-hosted bundle:

<script>
  window.SlaterSearchConfig = {
    endpoint: "https://api-dev.slater.app",   // remove once your site is synced to prod
    lists: { blog: { collection: "blog-posts" } }
  };
</script>
<script src="https://api-dev.slater.app/embed/v1/slater-search.js" defer></script>

lists["<key>"].endpoint overrides the endpoint for a single list, when you need to mix.
Your *.webflow.io staging domain automatically routes to the staging index — no extra setup.

Script caching & versions

The bundle at https://api.slater.app/embed/v1/slater-search.js is served with a 5-minute cache plus ETag revalidation — deliberately not immutable — so new builds reach visitors within minutes with no action on your side.

Waiting on a just-shipped Slater fix? Bump a version query on your script tag (…/slater-search.js?v=2) to force immediate pickup. The number is yours — it's a cache-buster convention, not a release channel, and bumping it is never required.