Use FileDeck with Astro, Next.js or any front end Pro

Running WordPress as a headless backend behind an Astro, Next.js, SvelteKit or plain-HTML front end? Your FileDeck library still works there. There are three integration levels, from zero-code to markup-you-control.

1. The embed snippet (zero code)

The fastest path is the same one-line snippet that works on Wix or Shopify — see Publish your library on another website:

<script src="https://example.com/?filedeck_embed_js=TOKEN" async></script>

Drop it into any Astro component or Next.js page (in Next, inside a client component or with next/script). You get the complete library — search, filters, previews, downloads, tracking — inside an isolated, self-resizing iframe. Nothing to build or keep in sync.

This is the right choice when the library is a page on your site. Read on when you want the library’s data woven into your own markup.

2. The library fragment endpoint (server-rendered rows + JSON)

Every FileDeck library can be queried over REST. Generate a snippet in Documents → Settings → Publish and take the TOKEN from it — that token is a signed description of which library, rendered how, and it’s the credential the endpoint expects. Then:

GET https://example.com/?rest_route=/filedeck/v1/library&ctx=TOKEN&page=1&per_page=25

The response is JSON:

• html — render-ready rows (or cards) for that page, with working preview, download and tracking markup. Print it inside your own wrapper and bring the FileDeck stylesheet, or restyle it entirely — it’s plain, class-namespaced HTML (fdk-*).
• total, page, per_page — real pagination numbers, computed in SQL.
• index — structured metadata per row: title, cat, tags, type, size, date, thumb. Useful for building your own cards, search-as-you-type, or a sitemap.
• q, cat, tag, orderby, order parameters filter and sort exactly like the on-site library; content search (searching inside files) works too.

Fetch it server-side for the best results — at build time in Astro, or in route handlers/getServerSideProps in Next.js — so the rows arrive pre-rendered with your page. Browser-side fetch() from another origin also works (WordPress’s REST API answers cross-origin GET requests), which is handy for live search and pagination after the first paint. Either way, a token generated for an embed enforces the same rule embeds have: restricted documents are excluded server-side, whoever asks.

3. Downloads and protected files

Public document downloads are ordinary URLs in the fragment HTML — they work from any origin and still count in your download analytics.

Protected files live in FileDeck’s deny-all vault and stream only after an access check. From a decoupled front end, share them with signed expiring links: the signature travels in the URL (fdk_sig/fdk_exp), needs no cookie, and therefore works wherever the link is rendered — including static sites and emails.

Choosing a level

You want	Use
The library on a page, five minutes, no build step	The embed snippet
Library rows inside your own layout and design system	The fragment endpoint, server-side
Individual protected files linked from anywhere	Signed expiring links

The three compose: many headless sites use the fragment endpoint for a browsable library page and signed links for gated downloads elsewhere.