Dynamic routes and data

Choose Request or Repeat

Use a Request block when an endpoint returns one object. Use a Repeat block when a list should create one visual subtree per item. Published requests resolve on the server before HTML is returned.

Use route and query values

A page slug may contain named parameters such as blog/:slug. Pass the matched values into the published-page context:

{
  params: { slug: "introducing-pagiera" },
  query: { preview: "true" },
  page: { slug: "blog/:slug" }
}

Reference those values in request URLs, headers or bodies:

https://api.example.com/posts/{{params.slug}}
https://api.example.com/search?q={{query.q}}

Bind returned fields

Connect text, images, links and visibility rules to fields returned by the request. For Repeat blocks, each repeated subtree receives the current item as its local data context.

Handle loading and failure

Server rendering has no client-side loading phase for published output. Design empty and error states explicitly. An upstream 404 can turn the complete route into a 404 response when the data source uses the page-404 behavior.

Keep pages indexable

Do not move essential content into an effect that runs after hydration. Confirm with “View Source” or an HTTP request that titles, descriptions and primary page copy are present in the returned HTML.