Overview
Running an online casino platform means keeping thousands of game listings, multilingual descriptions, structured reviews and player-facing copy fresh — work that simply doesn't scale by hand. I built the whole production line in n8n, orchestrated across Google Gemini, Anthropic Claude and Vertex AI RAG, with Scrapfly for scraping and Google Cloud Storage for the corpus, all landing in a Payload CMS running on Next.js. Six of the seven workflows are the editorial operation, run by content managers who never see anything but a form; the seventh is a developer harness that exists so engineers can test layouts and the publishing API without hand-filling lorem ipsum.
The seven workflows and what they do:
- Casino 1 — Scrapfly scraper. The data ingestion layer. It scrapes casino websites via Scrapfly, converts HTML to clean Markdown, and pushes the content into Google Cloud Storage ready for RAG indexing.
-
Cloud Storage. A reusable utility subworkflow. Called by other workflows whenever they need to fetch a stored document from GCS. Accepts
casino_domainandcasino_slugvia webhook. - Casino Subworkflow — Vertex RAG. The RAG engine. Handles corpus lookup, filtering and semantic search against Vertex AI. Also reusable — called by the main casino pipeline.
- Casino 2 — Main review pipeline. The most complex workflow. Combines Cloud Storage retrieval, Vertex AI RAG, Gemini for structured outline generation, Gemini for section-by-section writing, and Anthropic Claude for multilingual translation. The full end-to-end review factory.
- Games. Manages the game catalog: reconciles the Celesta provider list against NovaSpins, deletes stale games, then enriches new ones with Gemini-written descriptions and reviews, provider/tag/bonus taxonomy mapping, and multilingual support. Publishes as Lexical JSON.
- Reviews. Form-triggered player review generator. Loops to produce multiple realistic player reviews per casino, with Google Translate plus Gemini post-editing for non-English targets.
-
Publishing. Not part of the editorial operation — a nine-lane developer harness, one lane per CMS content type, each following the same
Schedule Trigger → AI Agent → Lexical conversion → Publishshape. It exists to get real content into a real layout in seconds and to confirm the publishing API still works after a deploy.
Architecture
The whole pipeline in one picture: content ingested from casino sites and source documents, processed through n8n, passed to Gemini, Claude and Vertex AI for generation, held in Cloud Storage and the Vertex RAG index, then assembled, translated, quality-checked, converted to Lexical JSON and published into the Payload CMS running on Next.js.
Every workflow laid out node by node, with the cross-workflow calls drawn as dashed lines — the review pipeline calls the RAG engine and the Cloud Storage utility rather than reimplementing either, while the nine publishing lanes sit alongside the content types they write. The colour coding separates storage and fetch steps from Vertex AI RAG, Gemini, Claude, translation/QA and publish nodes.
| Workflow | Purpose |
|---|---|
| Casino 1 — Scrapfly scraper | Scrape casino pages and prepare raw content for RAG |
| Cloud Storage — fetch utility | Retrieve and summarise stored documents from GCS |
| Casino Subworkflow — Vertex RAG | RAG corpus management and semantic search |
| Casino 2 — main review pipeline | The end-to-end review factory |
| Games | Catalog reconciliation and AI-generated game content |
| Reviews | Player review generation from a form submission |
| Publishing — developer harness | One lane per CMS content type, for layout testing and API verification |
The ingestion layer
Two workflows do the plumbing: one pulls content in, the other hands it back out on request.
Casino 1 — Scrapfly scraper
The full Casino 1 canvas: form trigger and domain validation, the Scrapfly → Markdown chain, and the Cloud Storage upload fan-out.
This is the data ingestion layer. A trigger takes a casino domain or a list of URLs, a Code node normalises it and builds the page list, and Scrapfly then fetches each page rendered server-side — the part that matters, because casino sites are JavaScript-heavy and a plain HTTP fetch returns an empty shell. The HTML is converted to clean Markdown, aggregated into one array, and written to Cloud Storage as a .txt, ready to be vectorised and indexed in Vertex AI Search. Validation happens up front: a missing domain stops the run before anything is scraped.
Cloud Storage — the fetch utility
The smallest canvas in the system: a webhook, three guard clauses, and a loop over the file array.
The other half of the plumbing, and deliberately minimal: a webhook accepts casino_domain and casino_slug, guard clauses check the parameters exist and the bucket resolves through a Google Service Account, and the stored Markdown goes back out through Respond to Webhook. It has no ideas of its own, and that's the point — retrieval lives in one place instead of being duplicated across every workflow that needs a document.
The RAG engine
Three corpus POST/response triples across the top, the RAG query path along the bottom.
This is the most technically interesting piece of the system, and the point at which the pipeline stops being "an LLM writing casino copy" and starts being something you can actually trust. It handles every interaction with Vertex AI's RAG corpus — fetching, filtering, and semantic searching — and the review pipeline leans on it twice: once to ground the outline, then again for every section it writes.
Key steps:
- Webhook Trigger — Entry point for subworkflow calls.
-
Validate Parameters — Checks for the required casino-specific parameters, throwing two different
Stop and Errornodes depending on which validation fails (general parameters versus casino-specific ones). - Split Out: Extract Corpuses — Splits the list of Vertex AI corpora into individual items for processing.
- Filter: Corpus from Parameter — Filters down to only the corpus matching the casino being processed.
- If: Parameters Exist — Final gate before querying.
- Vertex AI RAG Query — Performs a semantic similarity search against the indexed casino content.
- Extract Summary — Parses and returns the top relevant chunks to the parent workflow.
Reusability is the design. Any workflow needing RAG retrieval simply calls this webhook with a corpus and a query. Neither caller nor callee knows anything about the other's internals, which is what keeps the retrieval logic in one place as the corpus grows.
The corpus carries two kinds of truth. The indexed content isn't only operator facts — bonus terms, game catalogues, payment methods, licence details. It also carries the per-country legal and regulatory rules the copy has to comply with. That second kind is what makes the engine genuinely valuable in a regulated market: a review generated for one country can't carry claims that are unlawful in another, and retrieval enforces that without an editor looking the rules up from scratch on every draft. It is the difference between grounding that stops a model inventing bonus terms, and grounding that keeps the output legal.
The review pipeline
The core review pipeline: validation, Gemini/RAG generation, then aggregation and publish.
The centrepiece of the system and its most complex workflow. Everything the previous sections built — the scraped corpus, the stored documents, the RAG engine — converges here into a finished, publish-ready casino review, combining RAG retrieval, structured outline generation, section-by-section writing and multilingual translation.
Trigger
An n8n Form Trigger titled "Casino to Generate Overview" collects the casino domain, slug and target language from an operator. No developer involvement.
Stage 1 — Input validation
- Code: Extract Website Domain — Normalises the submitted URL.
- Code: Validate URLs — Custom JS validates URL format.
-
If: Website Domain Exists — Routes valid versus invalid inputs; invalid ones hit
Stop and Error: Missing Website.
Stage 2 — Content retrieval
- Cloud Storage Subworkflow call — Fetches the existing scraped Markdown content from GCS using the fetch utility.
- Vertex RAG Subworkflow call — Queries the relevant Vertex AI corpus, retrieving semantically relevant content chunks for the casino being reviewed, together with the regulatory rules that apply to the target market. Both reach the model in the same retrieval step, which is what keeps a review compliant for its country without an editor looking the rules up separately.
Stage 3 — Gemini outline generation
- Gemini API: Generate Outline — Given the retrieved content, Gemini produces a structured outline for the casino review (sections like Welcome Bonus, Game Selection, Payments, and so on).
Stage 4 — Section-by-section writing
- Gemini RAG Query per Section — For each section in the outline, Gemini is called again with a targeted RAG query to fetch the most relevant source material.
- Gemini: Write Section Content — Each section is written using both the outline and the retrieved context, which is what keeps it factually grounded.
Stage 5 — Translation with Anthropic Claude
- If: Language != 'en' — If the target language is not English, the content is routed to the translation branch.
- Anthropic Claude: Translate Sections — Claude handles nuanced multilingual translation of each section, preserving tone and iGaming terminology.
- Merge translated and non-translated — Both branches converge before final publishing.
Stage 6 — Publishing
- The final structured review is assembled and sent to the NovaSpins backend API.
This workflow is the clearest example of multi-model AI orchestration in the system: Gemini handles research and writing, Claude handles translation, and Vertex AI RAG provides the factual grounding.
Games catalog
Reconciliation feeds the enrichment webhook, which fans out into Gemini search, review and description branches.
This workflow keeps the NovaSpins game library in sync with the upstream provider (Celesta) — and unlike everything else in the system, it deletes as well as creates.
Reconciliation. A scheduled run pulls the full Celesta list and the current live list, then hands both to Gemini to diff. What comes back isn't text but a decision: which games to add, which to remove. The workflow acts on the removals with a DELETE call. Treating catalog maintenance as a reconciliation problem rather than a content problem is the interesting part — the model is being used as a comparator, not a writer, and its output drives state changes on the platform.
Enrichment. Each new game fans out through Gemini for the game's details (RTP, volatility, features, provider), a full written review, and a shorter SEO description. Non-English targets go through Google Translate and then Gemini again as a post-editor. Finally the workflow resolves taxonomy relationships — provider, tags, casinos, bonuses — fetching the existing entries and creating any that are missing, so a newly published game arrives already linked into the catalog instead of as an orphan record.
Player reviews
The review pipeline's validation front-end, with a multi-result player-review loop in place of the review stages.
A form-triggered generator for player-perspective reviews — the first-person kind you'd see on a comparison site. It validates the domain, then loops a Gemini call to produce several reviews per casino rather than one, and for non-English targets passes each through Google Translate with Gemini post-editing. The reviews are aggregated into a single payload and emitted as JSON, ready to publish.
The developer harness
Nine publishing lanes on one canvas, each wrapping the same Schedule Trigger → AI Agent → Lexical → Publish shape.
This one is not part of the editorial operation. Where the other six workflows each own a single pipeline, this packs nine independent lanes into one canvas — one per content type the CMS accepts, 54 nodes in total — all sharing the same four-stage shape: Schedule Trigger → AI Agent → Markdown-to-Lexical → Publish. Engineers run it by hand to get real content into a real layout within seconds, and to confirm the publishing API still behaves after a deploy; nothing it produces is meant to be read by a player.
| Lane | Trigger | Model | Endpoint |
|---|---|---|---|
| Casino article | Schedule Trigger Post Test Casino n8n |
Claude Sonnet 4.6 | POST /api/casinos/ |
| Casino update | Schedule Trigger n8n casino update |
Gemini 3 Flash | PATCH /api/casinos/{id} |
| Casino review | Schedule Trigger n8n review Update |
Gemini 3 Flash | PATCH /api/casinos/{id} |
| Bonus | Schedule Trigger Post Bonus |
Gemini 3 Flash | POST /api/bonuses |
| Game | Schedule Trigger Games n8n |
Gemini 3 Flash | POST /api/games/ |
| Guide | Schedule Trigger Guides n8n |
Gemini 3 Flash | POST /api/guides/ |
| News | Schedule Trigger News n8n |
Gemini 3 Flash | POST /api/news/ |
| Guest review | Schedule Trigger Review Casino |
(none — static payload) | POST /api/reviews/ |
| User review | Schedule Trigger Review Casino jr letto |
(none — static payload) | POST /api/reviews/ |
Six lanes run on models/gemini-3-flash-preview. The exception is the casino-article lane, wired to claude-sonnet-4-6 — the same split between Gemini for volume and Claude for the high-value piece that runs through the rest of the system.
Where the content lands: the CMS
Everything above is the production side. The workflows write into a Payload CMS — a Next.js application hosted on AWS — that holds both the content and the taxonomy it hangs off.
The Payload admin. Collections map onto what the workflows post to, and the System Data block supplies the UUIDs they reference.
The Casinos collection — records created by the workflows, not typed by hand.
The same records rendering on the public site: the homepage casino cards block.
The comparison row — welcome offer, payment methods, withdrawal speed, RTP range and providers, all separate fields rather than free text.
News and guides, through the same pipeline.
Stack
| Layer | Technology |
|---|---|
| Orchestration | n8n (self-hosted) |
| AI Writing & Reasoning | Google Gemini (via Vertex AI API) |
| AI Translation QA | Google Gemini |
| AI Translation (multilingual) | Anthropic Claude |
| Semantic Search / RAG | Vertex AI Search & Conversation (RAG) |
| Document Storage | Google Cloud Storage |
| Web Scraping | Scrapfly |
| Auth | Google Service Account (OAuth2) |
| CMS | Payload CMS (headless) |
| Frontend | Next.js |
| Hosting | AWS |
| Content Format | Lexical JSON (Payload rich text) |
| Platform API | NovaSpins REST API |
Conclusion
This system replaced what would otherwise be weeks of manual content work per month. It handles game catalog management, casino review writing, player review generation and multilingual localisation — all triggered from simple forms or schedules, with no developer intervention required for routine runs. It also ended up serving two very different audiences from one codebase: content managers, who only ever see a form, and engineers, who kept a harness workflow for testing layouts and the API.
Two decisions did most of the work. The first was modularity over monoliths — giving every workflow a single responsibility, and factoring the RAG engine and the Cloud Storage fetch into reusable subworkflows the review pipeline calls rather than copies. That is what makes the system cheap to extend: a new content type means a new lane, not a rebuilt pipeline. The second was RAG for factual grounding — never letting a model invent casino details when retrieval can supply them. Because the corpus holds both operator facts and the per-country regulatory rules, a non-lawyer operator can generate market-appropriate copy without a compliance review on every draft.
The key insight is that n8n is not just a task runner — it's a workflow orchestration layer that lets you compose AI APIs, storage services and platform APIs into coherent, maintainable pipelines. Combined with the right models and a RAG backbone for factual grounding, it becomes a serious content production engine.
If you're building content automation for a platform with a large and dynamic catalog, this modular approach — scrape → store → retrieve → generate → translate → publish — is a pattern worth stealing.
Top comments (0)