Light
Dark
All diagrams Technical architecture →
Candid Leap · WF-Algolia

How content becomes searchable

Sync and search are independent halves — use either on its own, or together for the full pipeline.

A · Sync the data optional
B · Search UI optional
Webflow

CMS content

Collections, items and fields live in Webflow — the source of truth.

Webhookinstant, on publish
Manualone click
Scheduledhourly cron
Recoveryauto-replay
4 ways a sync starts — no export needed
1
Change event
(signed & verified)
Cloudflare

Received at the edge

The event is authenticated and placed on a durable queue — only IDs travel here, never content.

retries, 30 min apart
14 dmessage retention
Nothing gets lost
2
Queued, delivered
at-least-once
WFA backend · Railway

Sync engine

Our backend service fetches the changed items from Webflow, applies the customer's field mapping, and writes records in batches.

5 mindead-letter replay
100 KBrecord size guard
Idempotent · auto-retry · resumable
3
Records indexed
in batches
Algolia

Search index

The customer's own Algolia index holds the live, search-ready records.

secspublish → searchable
1record per locale
Customer-owned — where sync and search meet
4
Query and results,
directly from the browser
Live site

Visitor searches

Our script on the published site renders search, filters and browse UI — talking to Algolia directly.

~msresult round-trip
0calls to our servers
Our backend is never in the search path
Two ways to get searchable
Sync the data (A) — connect the CMS and we keep the index fresh automatically·Bring your own Algolia (B) — already have a populated index? Use the search UI on its own
What gets synced
Only the fields you map are indexed — nothing else leaves the CMS·rich text is flattened to plain search text·every enabled locale gets its own record
Security model
Webhooks are HMAC-signed·API credentials are stored encrypted (AES-256-GCM) and never leave the backend·the browser only ever sees a public search-only key