Bind API data to a visually designed page
How do you bind live API data to a page in Pagiera?
Add a Request block to fetch one object or a Repeat block to iterate an array, then reference route parameters and query fields inside the URL, headers or body using {{params.x}} and {{query.x}} placeholders. For published pages both resolve on the server before HTML is returned, so API-backed content is present in the initial response rather than filled in afterwards.
Key points
- Request blocks expose one returned object to their descendants; Repeat blocks iterate an array result.
- Placeholders such as {{params.slug}} and {{query.q}} work in URLs, headers, query fields and bodies.
- Published pages resolve both block types on the server, so the data is in the HTML crawlers receive.
- An upstream 404 can turn the whole route into a 404 when the source uses the page-404 behavior.
Give the page a dynamic slug
A page slug can carry named parameters. The matched values are handed to the server context when the page renders.
blog/:slugFor a request to /blog/1, the context passed to the server looks like this:
{
params: { slug: "1" },
query: { preview: "true" }
}Reference the context from the data source
Request URLs, headers, query fields and bodies may all reference context values with double-brace placeholders.
https://dummyjson.com/posts/{{params.slug}}
https://api.example.com/search?q={{query.q}}Choose between Request and Repeat
| Block | When to use it |
|---|---|
| Request | The endpoint returns one object and you want to bind its fields to elements directly. |
| Repeat | The endpoint returns an array and you want to render every item with the same design. |
NoteRepeat is only needed when you want to render every item in a list. If you are binding a single record, a Request block alone is enough.
Why server-side resolution matters
Client-side fetching leaves the first response empty, which is what makes many visually built pages invisible to crawlers and answer engines. Pagiera finishes Request blocks before the HTML is returned, so the content a crawler reads is the content a visitor sees.
Frequently asked questions
Which HTTP methods can a data source use?
GET, POST, PUT, PATCH and DELETE data sources are supported, and request URLs, headers, query fields and bodies can all reference route parameters and query values.
Is API data visible to search engines?
Yes for published pages. Request blocks are resolved on the server and finish before HTML is returned, so API-backed content is part of the initial response rather than loaded afterwards in the browser.
What happens when the upstream API returns 404?
When the data source uses the page-404 behavior, an upstream 404 turns the complete route into a 404 page instead of rendering an empty layout.
