DEV Community: N4N1T0

Use Claude Code with Any Model via OpenRouter

N4N1T0 — Wed, 04 Nov 2026 16:30:00 +0000

I've been using Claude Code for a while, and at some point a question stuck: what if I don't want Claude as the model behind Claude Code?

It turns out the tool is more flexible than it looks. Claude Code reads a set of environment variables that control where its API requests go and which model each role uses. The important one is ANTHROPIC_BASE_URL: it points Claude Code at any endpoint that speaks the Anthropic Messages API, not only Anthropic's own.

Anthropic documents this for LLM gateways, and OpenRouter ships an Anthropic-compatible endpoint built for exactly this case.

OpenRouter as the gateway

Instead of talking to Anthropic directly, Claude Code can talk to:

https://openrouter.ai/api

OpenRouter is one API in front of hundreds of models from dozens of providers, with a single key and a single bill. Claude Code keeps speaking its native protocol, and OpenRouter translates the request for whichever model you picked. No local proxy in between.

So you keep the Claude Code interface, its tools, the agent loop and the terminal experience, and you swap what sits underneath.

One caveat before going further. Claude Code is tuned for Anthropic's API semantics: tool calls, streaming, extended thinking. A non-Anthropic model may handle some of that worse, or not at all. OpenRouter itself recommends Anthropic's first-party provider for full compatibility. Treat other models as an experiment, not a drop-in.

The environment variables

Three variables do the redirect:

export ANTHROPIC_BASE_URL="https://openrouter.ai/api"
export ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY"
export ANTHROPIC_API_KEY=""

ANTHROPIC_BASE_URL sends every request to OpenRouter.
ANTHROPIC_AUTH_TOKEN authenticates with your OpenRouter key.
ANTHROPIC_API_KEY must be explicitly empty. If it holds a value, Claude Code can fall back to its normal Anthropic auth. The OpenRouter integration guide calls this out too.

Then the model overrides. Claude Code uses model aliases internally (opus, sonnet, haiku, fable) plus a separate default for subagents. Each has its own variable, documented here:

export ANTHROPIC_DEFAULT_FABLE_MODEL="$MODEL"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$MODEL"

Set all of them. If you only change the main model, background tasks and subagents keep asking for a Claude model by alias, and you end up running two models without noticing.

Exporting eight variables by hand every time gets old, so I wrapped it in a command.

The `orclaude` script

The interface:

orclaude <vendor/model-slug> [claude args...]

For example:

orclaude anthropic/claude-sonnet-5.5
orclaude openai/gpt-6.1-sol

The script:

#!/usr/bin/env bash

# Run Claude Code against any OpenRouter model:
# orclaude <vendor/model-slug> [claude args...]

: "${OPENROUTER_API_KEY:?Set OPENROUTER_API_KEY in your shell profile}"

MODEL="${1:?Usage: orclaude <vendor/model-slug> [claude args...]}"
shift

export ANTHROPIC_BASE_URL="https://openrouter.ai/api"
export ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY"
export ANTHROPIC_API_KEY=""

export ANTHROPIC_DEFAULT_FABLE_MODEL="$MODEL"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$MODEL"

exec claude --model "$MODEL" "$@"

The variables only live in that process. Your normal claude session stays on your usual account, and orclaude is the OpenRouter one. No proxy, no Docker container, no fork of Claude Code.

To confirm it took, run /status inside the session. It should show the auth token as the source and https://openrouter.ai/api as the base URL.

A native `orclaude` command in PowerShell

On Windows, add a wrapper to your PowerShell profile (notepad $PROFILE) so orclaude behaves like any other command:

function orclaude {
    & "$HOME\Scripts\orclaude.ps1" @args
}

Since the model is only an argument, the PowerShell version can also keep a shortlist of favorites and let you pick one by number:

# Run Claude Code against any OpenRouter model:
# orclaude <vendor/model-slug | list number> [claude args...]

$Models = @(
    "anthropic/claude-sonnet-5.5"
    "openai/gpt-6.1-sol"
    "google/gemini-3.8-flash"
    "deepseek/deepseek-v4.1-flash"
)

if ($args.Count -eq 0 -or $args[0] -in @("-help", "--help", "-h")) {
    Write-Host ""
    Write-Host "Available models:" -ForegroundColor Cyan
    for ($i = 0; $i -lt $Models.Count; $i++) {
        Write-Host "  [$($i + 1)] $($Models[$i])"
    }
    Write-Host ""
    exit 0
}

if (-not $env:OPENROUTER_API_KEY) {
    Write-Error "Set OPENROUTER_API_KEY in your environment"
    exit 1
}

$Model = [string]$args[0]
if ($Model -match '^\d+$') {
    $Index = [int]$Model
    if ($Index -lt 1 -or $Index -gt $Models.Count) {
        Write-Error "No model #$Index. Run orclaude -help to see the list."
        exit 1
    }
    $Model = $Models[$Index - 1]
}
$ClaudeArgs = @($args | Select-Object -Skip 1)

$env:ANTHROPIC_BASE_URL = "https://openrouter.ai/api"
$env:ANTHROPIC_AUTH_TOKEN = $env:OPENROUTER_API_KEY
$env:ANTHROPIC_API_KEY = ""

$env:ANTHROPIC_DEFAULT_FABLE_MODEL = $Model
$env:ANTHROPIC_DEFAULT_OPUS_MODEL = $Model
$env:ANTHROPIC_DEFAULT_SONNET_MODEL = $Model
$env:ANTHROPIC_DEFAULT_HAIKU_MODEL = $Model
$env:CLAUDE_CODE_SUBAGENT_MODEL = $Model

& claude --model $Model @ClaudeArgs
exit $LASTEXITCODE

Two details in there are easy to get wrong:

@($args | Select-Object -Skip 1) instead of $args[1..($args.Count - 1)]. With a single argument, that range becomes 1..0, which PowerShell walks backwards, so the model slug gets passed to claude a second time as a stray argument.
In PowerShell, assigning "" to an environment variable removes it for the current process. For ANTHROPIC_API_KEY that is what we want: no key left to fall back to.

Now orclaude -help prints the list:

Available models:

  [1] anthropic/claude-sonnet-5.5
  [2] openai/gpt-6.1-sol
  [3] google/gemini-3.8-flash
  [4] deepseek/deepseek-v4.1-flash

and orclaude 3 starts a session on the third one. A number outside the list fails with a message instead of launching Claude Code with an empty model.

macOS and Linux

For macOS or Linux, the Bash script above is the whole setup. Save it as orclaude somewhere in your $PATH and make it executable:

chmod +x orclaude

Then:

orclaude <vendor/model-slug>

If you'd rather have every session go through OpenRouter, put the variables in ~/.zshrc or ~/.bashrc instead. That is the persistent setup OpenRouter recommends. Claude Code does not read .env files, so the shell profile is the place.

Why the split matters

The script is short. The interesting part is the architecture it exposes.

Claude Code is the harness: the tools, permissions, the agent loop, the terminal UI. The model is a separate layer, and the harness does not need to come from the same vendor as the model.

So instead of:

Claude Code → Claude

the stack becomes:

Claude Code → Anthropic-compatible gateway → model

With OpenRouter as that middle layer you get one API key, one bill, one catalog, provider routing with failover, and usage tracking in one dashboard. Switching models is an argument, not a migration.

You keep the Claude Code workflow you already know, and you can still find out what a different model does inside it.

Astro 5: What Changed and Why It Matters for SEO

N4N1T0 — Wed, 28 Oct 2026 16:30:00 +0000

What Astro actually changes

Astro is not a redesign of the web, and that is the point. Three changes closed the gaps that used to push a team back to a full framework: content from anywhere, per-component server rendering and typed environment variables. They landed in Astro 5 and still shape the framework today.

Content Layer

Before the Content Layer, a collection had to be local Markdown or a CMS fetched by hand. Astro introduced loaders, so a collection can read from the filesystem, a CMS API or a database and still expose the same getCollection() API:

import { defineCollection } from 'astro:content';
import { z } from 'astro/zod';
import { glob } from 'astro/loaders';

const blog = defineCollection({
    loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
    schema: z.object({
        title: z.string(),
        date: z.coerce.date(),
        excerpt: z.string().max(160),
    }),
});

The practical gain is validation. The schema runs at build time, so a missing title or a date typed as a string breaks the build instead of the page. The Content Layer API is also what later versions build on, including the global content layer and live collections.

Server islands

Astro has always rendered pages statically and hydrated only interactive islands. Server islands extend the idea to the server: a component can be rendered on demand, after the static shell, and streamed into the page.

That fits a narrow but common case: a price, a stock counter or a "signed in as" block that must be fresh, inside a page that is otherwise cacheable. The static shell reaches the browser immediately and the dynamic fragment fills in later.

It does not replace SSR for the whole page. A dashboard where every block depends on the session is still a server-rendered app; wrapping each block in a server island only adds latency.

`astro:env`

Environment variables moved from import.meta.env scattered across the code, with no validation, to a declared schema:

import { defineConfig, envField } from 'astro/config';

export default defineConfig({
    env: {
        schema: {
            PUBLIC_SITE_URL: envField.string({ context: 'client', access: 'public' }),
            REDSYS_SECRET: envField.string({ context: 'server', access: 'secret' }),
        },
    },
});

A secret imported into client code now fails at build time, which is the kind of mistake that used to reach production.

The SEO question

Astro does not rank better because it is Astro. It ranks because of what it ships to the crawler: complete HTML, no render-blocking framework, small pages. The wins are concrete:

Content is in the HTML. A static page arrives with the full text. Googlebot executes JavaScript, but it does it on a budget; a page that needs no execution is indexed sooner and with fewer surprises.
JavaScript is opt-in. A blog post with one interactive island ships the island, not the whole app. Less script means better Interaction to Next Paint, which is a Core Web Vital.
The HTML is the source. There is no hydration mismatch, no empty <div id="root"> waiting for a bundle.

What Astro does not fix by itself: images without dimensions, fonts that block the first paint, or a page whose content answers nothing. Those are Content and Core Web Vitals problems, not framework problems. I cover the on-page side in SEO optimization.

When a SPA is still the right call

Static-first is a bad fit when the page is the application. If the whole screen depends on the logged-in user, updates every few seconds and has no meaningful pre-render, the static shell is mostly a loading state. A client-rendered app behind authentication is simpler to reason about.

Astro handles this with SSR and server islands, but that is a middle ground. Choose it when the page has a public, cacheable core and a small dynamic edge. Choose a SPA when almost every pixel is dynamic.

Upgrading from Astro 4

Coming from Astro 4, the upgrade errors are mostly honest, and each one points at a real change:

Content collections move to loaders. type: 'content' entries are replaced by glob() or file() loaders, and entry.slug becomes entry.id. Templates that used slug need updating.
entry.render() is gone. Render through render(entry) imported from astro:content, which also returns the Content and headings used by layouts.
Output modes are simplified. hybrid disappears; static output with per-route prerender = false covers the same case.
astro:env needs a schema. Existing variables still work through import.meta.env, but the typed API requires declaring them.

None of these are cosmetic: each one replaces an implicit behaviour with an explicit one, which is why the migration tends to leave a cleaner content layer.

How I use it here

This site is a static Astro build: content collections for posts and projects, Preact islands only where there is state, and a terminal prompt that is the only client-heavy component. The result is a build that produces plain HTML per route and ships script for one island, not for the site.

If you are weighing Astro against a SPA for a content-heavy product, tell me about the project and I will tell you which parts should stay static. If your forms need server work, Astro Actions with vanilla JS forms covers the pattern without a client framework.

Astro Actions and Vanilla JavaScript for Forms

N4N1T0 — Tue, 26 Aug 2025 14:16:27 +0000

One of the features I've been enjoying in Astro lately is the Actions API. It allows you to handle server logic (like form submissions) without spinning up a full backend or reaching for a heavy framework.

Here's how I used it to build a contact form that:

Validates input on the server with astro:schema (powered by zod)
Adds extra client + HTML validation for smoother UX
Updates the UI with vanilla JavaScript using a Starwind UI Alert component

🗂️ Frontmatter vs Client-Side Scripts in Astro

The frontmatter (--- ... ---) in an Astro file is always server-side. You can't touch the DOM there. But inside the Astro component, you can add a <script> tag, and it works just like a classic browser script — with full DOM access and module imports if needed.

That's the trick: Actions run server-side, but you can wire up responses with client-side scripts.

Example: Contact Form in Astro

// frontmatter: server-side only
import { buttonVariants } from '@/components/starwind/button'
import { Alert, AlertTitle, AlertDescription } from '@/components/starwind/alert'

---

<section>
  <!-- Contact Form -->
  <div class="max-w-xl mx-auto p-6 bg-gray-50 rounded-xl shadow">
    <h3 class="mb-4 text-2xl font-bold">Contact Us</h3>

    <Alert id="form-status" class="mb-4 hidden" variant="success">
      <AlertTitle>Status</AlertTitle>
      <AlertDescription>Waiting...</AlertDescription>
    </Alert>

    <form id="contact-form" method="POST" class="space-y-4">
      <input id="name" name="name" type="text" required placeholder="Your name" />
      <input id="email" name="email" type="email" required placeholder="Your email" />
      <textarea id="message" name="message" required placeholder="Your message"></textarea>

      <button type="submit" class={buttonVariants({ size: 'lg' })}>Send</button>
    </form>

  </div>
</section>

<script>
  import { actions } from 'astro:actions'

  const form = document.querySelector('#contact-form')
  const status = document.querySelector('#form-status')

  form?.addEventListener('submit', async (event) => {
    event.preventDefault()
    const formData = new FormData(form)
    const { error, data } = await actions.contact(formData)

    if (error) {
      status.classList.remove('hidden')
      status.querySelector('h5').textContent = 'Error'
      status.querySelector('div').textContent = error.message
      return
    }

    if (data) {
      status.classList.remove('hidden')
      status.querySelector('h5').textContent = 'Message sent ✅'
      status.querySelector('div').textContent = 'Thanks! We'll be in touch soon.'
      form.reset()
    }
  })
</script>

1️⃣ Frontmatter (Server-Side Only)

import { buttonVariants } from '@/components/starwind/button'
import { Alert, AlertTitle, AlertDescription } from '@/components/starwind/alert'

---

This block (--- ... ---) runs only on the server in Astro.
You can import components, utilities, or data here — but you can't touch the DOM.

2️⃣ The Markup (HTML + Components)

<section>
  <!-- Contact Form -->
  <div class='max-w-xl mx-auto p-6 bg-gray-50 rounded-xl shadow'>
    <h3 class='mb-4 text-2xl font-bold'>Contact Us</h3>

    <Alert id='form-status' class='mb-4 hidden' variant='success'>
      <AlertTitle>Status</AlertTitle>
      <AlertDescription>Waiting...</AlertDescription>
    </Alert>

    <form id='contact-form' method='POST' class='space-y-4'>
      <input
        id='name'
        name='name'
        type='text'
        required
        placeholder='Your name'
      />
      <input
        id='email'
        name='email'
        type='email'
        required
        placeholder='Your email'
      />
      <textarea id='message' name='message' required placeholder='Your message'
      ></textarea>

      <button type='submit' class={buttonVariants({ size: 'lg' })}>Send</button>
    </form>
  </div>
</section>

Standard form fields: name, email, message.
Each field uses HTML's built-in validation (required, type="email").
The button is styled with Starwind UI's buttonVariants.
The Alert component is hidden by default (hidden).
Later, when the form is submitted, this gets updated dynamically with success or error messages.

3️⃣ Client-Side Script (DOM Manipulation)

<script>
  import { actions } from 'astro:actions'

  const form = document.querySelector('#contact-form')
  const status = document.querySelector('#form-status')

  form?.addEventListener('submit', async (event) => {
    event.preventDefault()
    const formData = new FormData(form)
    const { error, data } = await actions.contact(formData)

    if (error) {
      status.classList.remove('hidden')
      status.querySelector('h5').textContent = 'Error'
      status.querySelector('div').textContent = error.message
      return
    }

    if (data) {
      status.classList.remove('hidden')
      status.querySelector('h5').textContent = 'Message sent ✅'
      status.querySelector('div').textContent = 'Thanks! We'll be in touch soon.'
      form.reset()
    }
  })
</script>

This <script> runs in the browser, not on the server.

Astro treats it like a classic JS script, but you can still import modules (actions).
Here, we grab references to the form and the hidden status alert.
Prevents default form submission (page reload).
Converts the form into FormData.
Calls the server-side contact action defined in Astro.
If there's a validation or server error, it shows the Alert with the error message.
If the action succeeds, the alert is updated with a success message.
Finally, the form is cleared (form.reset()).

⚠️ Don't Forget SSR

If you want Actions to run, the page must be server-side rendered (SSR). In Astro, you can disable prerendering like this:

// at the top of your Astro page
export const prerender = false

If you're deploying to Vercel, Netlify, or Node, your adapter will handle the rest.

✅ Why I Like This Approach

Lightweight → Almost zero JS shipped, except a tiny script for DOM updates.
Safe → Strong validation with zod on the server + extra checks in the client.
Flexible → Works with Astro's philosophy but doesn't force a full framework.
Modern + Old School → Server actions + vanilla DOM = best of both worlds.

Conclusion

Astro Actions provide a perfect balance between modern server-side functionality and lightweight client-side interactions. By combining server-side validation with vanilla JavaScript, you can create robust, performant forms without the overhead of heavy frameworks.

This approach is particularly powerful for contact forms, newsletter signups, and other simple interactions where you want the benefits of server-side processing without sacrificing user experience.

Automate Your Product Feed in Google Merchant Center with Node.js

N4N1T0 — Sun, 17 Aug 2025 14:42:08 +0000

In eCommerce, having an updated feed in Google Merchant Center is not optional.
It’s crucial for your Shopping campaigns to run smoothly, for your products to be approved quickly, and for your advertising performance to stay consistent.

Many CMSs offer plugins for this task, but they are often:

❌ Limited
❌ Hard to customize
❌ Inefficient for projects with real business needs

As an eCommerce developer, I’ve faced this need many times.
The best solution I found was to go straight to the source: Google Content API for Shopping.

In this article, I’ll show you how to automate your feed with Node.js, without unnecessary plugins, in a scalable and fully controlled way.

🧱 Step 1: Authenticate with a Service Account

Google provides an official library to work with its APIs in Node.js: 👉 googleapis

The client we care about is @googleapis/content, which connects directly to Merchant Center.

🔑 What is a Service Account?

A service account is a technical identity within Google Cloud that allows you to access APIs without human intervention. Perfect for automated backend processes.

✅ How to create one

Go to console.cloud.google.com and open your project.
Navigate to "IAM & Admin" → "Service Accounts"
Create a new account and assign the Editor role or a custom role with Content API permissions.
Download the .json credentials file.

🔐 Keep it secure

Never upload these credentials to Git!
Use environment variables:

GOOGLE_PRIVATE_KEY=-----BEGIN PRIVATE KEY-----...
GOOGLE_CLIENT_EMAIL=your-account@project.iam.gserviceaccount.com
MERCHANT_CENTER_ACCOUNT_ID=123456789

📌 To get your MERCHANT_CENTER_ACCOUNT_ID:
Go to Google Merchant Center, and at the top right (next to your profile picture), you’ll see your Account ID. That number is your merchantId.

🔒 Authenticate with GoogleAuth

import * as content from '@googleapis/content'

const authClient = new content.auth.GoogleAuth({
  credentials: {
    private_key: process.env.GOOGLE_PRIVATE_KEY,
    client_email: process.env.GOOGLE_CLIENT_EMAIL
  },
  scopes: [
    'https://www.googleapis.com/auth/content', // Full access to the Content API
    'https://www.googleapis.com/auth/cloud-platform' // Recommended by Google
  ]
})

const contentClient = content.content({
  version: 'v2.1',
  auth: authClient
})

The scopes define permissions:

content: create, update, and delete products.
cloud-platform: interoperability with other Google APIs.

🧩 Step 2: Insert or Update Products

The API provides two key methods:

products.insert() → Create a new product (only once per offerId)
products.update() → Update an existing product

⚠️ Using insert on an existing product will fail. Check if the product exists before calling it.

🛠️ Example Function

import { content_v2_1 } from '@googleapis/content'

const updateProduct = async (
  product: any,
  contentClient: content_v2_1.Content,
  isNewProduct: boolean
) => {
  try {
    const method = isNewProduct ? 'insert' : 'update'

    const updatedProduct = await contentClient.products[method]({
      merchantId: process.env.MERCHANT_CENTER_ACCOUNT_ID,
      requestBody: {
        offerId: product.id,
        title: product.title,
        description: product.description,
        price: {
          value: product.price.toFixed(2),
          currency: 'EUR'
        },
        salePrice: product.salePrice
          ? { value: product.salePrice.toFixed(2), currency: 'EUR' }
          : undefined,
        link: `https://yoursite.com/product/${product.slug}`,
        imageLink: product.imageUrl,
        additionalImageLinks: product.additionalImages || [],
        availability: product.stock > 0 ? 'in stock' : 'out of stock',
        condition: 'new',
        brand: product.brand,
        contentLanguage: 'es',
        targetCountry: 'ES',
        channel: 'online',
        gtin: product.gtin || null,
        mpn: product.mpn || null,
        identifierExists: !!product.gtin,
        googleProductCategory: product.googleCategory || null,
        productTypes: product.categories || [],
        salePriceEffectiveDate: product.salePrice
          ? '2025-03-01T23:00:00Z/2025-06-15T22:00:00Z'
          : null,
        pickupMethod: 'buy',
        canonicalLink: `https://yoursite.com/product/${product.slug}`
      }
    })

    return { success: true, product: updatedProduct }
  } catch (error: any) {
    console.error(`Error processing product ${product.id}:`, error)
    return {
      success: false,
      error: error.message,
      productId: product.id
    }
  }
}

📘 Full list of fields in the official documentation.

🔁 Step 3: Run Controlled Synchronization

Updating many products at once can cause throttling or network errors.
To prevent this, we use p-limit, which limits concurrent promises.

npm install p-limit

⚙️ Example

import pLimit from 'p-limit'

const limit = pLimit(5)

const updateResults = await Promise.all(
  products.map((product) =>
    limit(() => updateProduct(product, contentClient, product.isNew))
  )
)

This ensures only 5 processes run at the same time.

🎁 Bonus: Automate with a Daily Cron Job

Schedule syncs using node-cron or external services (EasyCron, GitHub Actions).

Example with node-cron:

import cron from 'node-cron'

cron.schedule('0 3 * * *', async () => {
  console.log('⏰ Updating products in Merchant Center...')
  await syncAllProducts()
})

This runs daily at 3:00 AM.

🚀 Conclusion

By using the Content API directly from Node.js, you unlock a first-class integration:

✅ Fully customizable
✅ No limiting plugins
✅ Optimized for scale and performance
✅ Compatible with any CMS or backend
✅ Future-proof for growth

In a world where automation makes the difference between selling or not, this integration can be the key to taking your Shopping campaigns to the next level.

Search and AI: The Dream Team for an eCommerce Revenue Boost

N4N1T0 — Tue, 20 May 2025 10:32:05 +0000

🧩 The Challenge: UX That Converts for Niche eCommerce

My client runs a personalized padel t-shirt eCommerce site. They wanted:

Faster and more relevant product search
The ability to personalize empty state experiences
Future integration with an AI chatbot

This wasn’t just about search — it was about making intelligent UX part of conversion rate optimization (CRO).

🚀 The Stack: Orama.search + OpenAI + Sanity

We chose Orama.search for its:

Lightweight architecture and speed
Native support for vector-based search (with OpenAI embeddings)
Developer-friendly API (can be updated via REST, CLI, SDKs)

It let us go beyond standard search to implement answer engine logic, automations, and personalized search outputs — all while staying fully headless.

🔄 Dynamic Product Updates (Sanity + Cron + GROQ)

Instead of manually syncing product data to the vector database, we automated the process using a scheduled cron job combined with a GROQ query from Sanity CMS. As developers, one of the most effective ways we improve user experience is by streamlining repetitive tasks—automation not only saves time but also reduces the risk of errors. Fortunately, Orama provides a straightforward API for handling updates, inserts, and deletions. Since we were working within the limitations of the free tier, we opted for a single deployment at a time—a practical and efficient solution that kept the system lightweight and cost-effective.

// /api/update-orama-db.ts

const manager = new CloudManager({
  api_key: process.env.ORAMA_PRIVATE_API_KEY!
})
const indexManager = manager.index('xxxxxxxxxxxxxxxxx') // Replace with id Index

export const GET = async () => {
  try {
    const products = await sanityClientRead.fetch(
      GET_ORAMA_PRODUCTS_FOR_UPDATING // GROQ query from Sanity
    )

    await indexManager.update(products)
    await indexManager.deploy()

    return NextResponse.json('OK', { status: 200 })
  } catch (error) {
    return NextResponse.json(
      { error: 'An error occurred', details: error },
      { status: 500 }
    )
  }
}

💡 Bonus: You can optimise the GROQ query to fetch only products that have changed since a specific timestamp.

🔍 The Search Page: UX Meets Relevance

This enhancement was part of a larger migration project from WordPress to Next.js with Sanity, which also included a full product refresh. As a result, much of the existing indexed content on Google became outdated. To address this, we added a 404 search fallback that triggers when a product URL no longer exists. It uses the missing slug to perform a hybrid search and return relevant product suggestions—helping retain traffic and reduce bounce rates during the transition period.

const { search } = await searchParams // Next.js 15 searchParams for the search page
çconst { slug } = await searchParams // Next.js 15 slug for the 404 page

const oramaResponse = await oramaClient.search({
  term: search/slug as string,
  mode: 'hybrid'
})

if (!oramaResponse) {
  log.error('Products not found', { oramaResponse })
}

We also leveraged past user behaviour and wishlist data to:

Prioritise recently viewed products in search results.
Insert smart call-to-actions directly within search listings.
Suggest relevant product bundles to boost quick checkouts.
Perform similarity-based searches to update last-minute offers with products sharing key characteristics.
Apply the same logic on the checkout page and product views, dynamically recommending bundles and tailored suggestions.

🎯 CRO Techniques Enabled

By combining AI-powered search with UX intelligence, we implemented:

✅ Personalized 404/empty search pages
✅ Wishlist-based smart carousels
✅ Product slug disambiguation (typo handling)
✅ Search result re-ranking based on behavioral insights

These micro-improvements reduced bounce rate and nudged more sessions into purchase flow.

🧠 Why Orama Over Meilisearch/Typesense/Algolia?

Open-source, lightweight and cost-effective
Built-in support for vector search + OpenAI embeddings
Native REST + CLI + SDK support for automation
Developer-focused design and instant local setup

It gave us AI-enhanced flexibility without the SaaS pricing headaches.

🔮 What’s Next: AI Chatbot Integration

The next phase of this project will bridge Orama with OpenAI to create an in-site product assistant. It will:

Guide users via chat toward relevant products
Pull real-time insights from the search index
Respond to wishlist/product queries

With Orama’s answer engine and embeddings already in place, this will be a smooth evolution.

Integrating Redsys with Next.js 15 – Part 2

N4N1T0 — Fri, 21 Mar 2025 15:21:09 +0000

Handling Payment Notifications Efficiently

The Challenge: Asynchronous Bank Processes

When integrating Redsys with Next.js, one challenge is handling payment notifications effectively. The bank-to-bank transaction process can take time, and users shouldn’t have to wait indefinitely for confirmation. Payment gateways, including Redsys, handle transactions on the backend, which means your system must be capable of capturing and processing the payment status reliably.

Another common scenario occurs when a user completes the payment on the bank’s website but does not return to your website. In such cases, your system must still be able to finalize the order correctly.

Implementing Redsys Payment Notifications

Redsys provides a built-in notification URL to handle these situations. You can configure this URL in the payment request:

const form = createRedirectForm({
  ...merchantInfo,
  // This URL is used by Redsys to send payment notifications to your server
  // It ensures that your backend receives transaction updates, even if the user does not return to your site
  DS_MERCHANT_MERCHANTURL: '/api/redsys/notification'
})

Creating the Notification API

To handle payment notifications, you need an API route that processes Redsys' response.

import type { ResponseJSONSuccess } from 'redsys-easy'
import { processRestNotification } from '@/lib/clients/redsys'
import { NextResponse } from 'next/server'

export async function POST(req: Request) {
  // Extracts the Redsys notification parameters from request headers
  const notificationParams: ResponseJSONSuccess = {
    Ds_SignatureVersion: req.headers.get('Ds_SignatureVersion') as string,
    Ds_Signature: req.headers.get('Ds_Signature') as string,
    Ds_MerchantParameters: req.headers.get('Ds_MerchantParameters') as string
  }

  // Processes the notification and extracts relevant payment details
  const { Ds_Order: orderId, Ds_Response: responseCode } =
    processRestNotification(notificationParams)

  // Checks if the payment was successful (response code '0000' indicates success)
  if (responseCode === '0000') {
    console.info('Order successfully updated', { orderId, responseCode })
    return NextResponse.json({ success: true, message: 'Payment completed' })
  } else {
    return NextResponse.json({ success: false, message: 'Payment failed' })
  }
}

This function verifies the Redsys notification, extracts the order ID and response code, and updates the order status accordingly.

Improving Performance with URL Parameters

Modern web applications rely heavily on state management, but in cases like Redsys transactions—where users leave the site and return—maintaining state can be difficult. A practical solution is to include key information within the URL.

For example, passing user-related data such as the user ID, address ID, products, and total amount in the redirect URL ensures you have everything needed to complete the order process once the user returns.

Implementing a Payment Logic Function

Using Next.js server actions, you can define a function that structures the redirect URLs dynamically

'use server'

const paymentLogic = async (
  paymentType: FormDataEntryValue | null,
  totalAmount: number,
  userId: string | string[] | undefined,
  products: CartItemType[],
  newAddress: string | string[] | undefined,
  discountCoupon: string
) => {
  // Generates a structured URL containing necessary payment details for redirection
  const templateRedirectUrl = (page: string, gateway: string = 'RedSys') => {
    return `${process.env.NEXT_PUBLIC_URL}/${page}?userId=${userId}&orderId=
    ${orderId}&gateway=${gateway}&newAddress=${newAddress}&discountCoupon=
    ${discountCoupon}&total=${totalAmount}&products=
    ${encodeURIComponent(JSON.stringify(products))}`
  }

  const form = createRedirectForm({
    ...merchantInfo,
    DS_MERCHANT_MERCHANTURL: templateRedirectUrl('api/redsys'),
    DS_MERCHANT_URLOK: templateRedirectUrl('success'), // This URL aims to the success page
    DS_MERCHANT_URLKO: templateRedirectUrl('failure') // This URL aims to the success page
    // All the rest info on the part 1
  })
}

Conclusion

Handling asynchronous payment notifications and maintaining order data when users leave and return to your site are essential for a smooth Redsys integration. By configuring a notification URL and passing key parameters through URLs, you can ensure a reliable and seamless payment process in your Next.js 15 application.

If you haven’t already, check out Part 1 where we cover setting up a Redsys client with all necessary functions!

How to Scrap Product for E-commerce with Sanity CMS and Cheerio

N4N1T0 — Thu, 06 Mar 2025 22:04:50 +0000

Introduction

Building e-commerce websites has always been an exciting challenge for me, especially when working on high-stakes projects like selling cosmetics from a well-known brand. Recently, I was tasked with building an online store for a client who was an official distributor for a cosmetic brand called "Loreal." (just kidding) The project seemed straightforward at first, but there was a twist — I needed to automate the process of importing products directly into the Sanity CMS from an external WordPress-based site.

Having worked on many e-commerce websites, I’ve always embraced new challenges, but this one was unique. With a source website built in WordPress and a public API at hand, I saw an opportunity to create a seamless automation process that could save the client a lot of time and effort. In this post, I’ll walk you through how I approached the task, the tools I used, and how I built an automated product import system that checks all the right boxes: efficient, scalable, and low-maintenance.

Scraping the Data

To kick things off, I needed to gather all the product information from the source website. Since the website was powered by WordPress, and the public API was exposed (be aware) the products’ names and links. At first glance, it seemed like an easy task: I could use a simple loop with search parameters like per_page and page to paginate through all the product listings.

const API_URL = 'https://example.com/wp-json/wp/v2/products'

async function fetchAllProductLinks() {
  let allProductDetails = []
  let page = 1
  let products = []

  try {
    // Keep fetching as long as there are products in the response
    do {
      const response = await fetch(`${API_URL}?per_page=20&page=${page}`)
      products = response.data
      // Push an object containing both link and name to the result array
      allProductDetails = allProductDetails.concat(
        products.map((product) => ({
          link: product.link,
          name: product.name
        }))
      )
      page++
    } while (products.length > 0) // Stop if no products are returned

    return allProductDetails
  } catch (error) {
    console.error('Error fetching product links and names:', error)
  }
}

With this code, I was able to easily collect all the product links. But the real work started when I needed to scrape detailed information from each individual product page. That's where Cheerio came in.

Cheerio is a fast and lightweight library that mimics jQuery, making it perfect for scraping HTML content from a page. I used it to load each product page and extract key details, such as the product name, description, images, and more.

const cheerio = require('cheerio')

async function scrapeProductDetails(url) {
  try {
    // this is a CORS proxy to bypass the CORS issue
    const { data } = await fetch(`https://cors-anywhere.herokuapp.com/` + url)
    const $ = cheerio.load(data)

    // Heres where you need to use your browser console skills to find the right selectors
    const productName = $('h1').text()
    const productDescription = $('meta[name="description"]').attr('content')
    const productImage = $('img.product-image').attr('src')

    return { productName, productDescription, productImage }
  } catch (error) {
    console.error('Error scraping product details:', error)
  }
}

Now that I had a way to scrape product details, I ran into a familiar problem — CORS errors. Since I was making requests from my server to an external API, the browser blocked the requests due to cross-origin restrictions. Fortunately, I was able to bypass this using Heroku CORS Anywhere, which acted as a proxy to resolve the CORS issue.

Validating and Enriching the Data

At this point, I had most of the product details I needed, but there was one crucial piece of information still missing — the price. My client provided me with a PDF that contained the distributor’s pricing information. To make sure I had accurate data, I needed to cross-reference the prices with the ones in the PDF.

Here, I turned to ChatGPT to help me extract the necessary details from the PDF. With a bit of prompt engineering (an article coming soon), I was able to create a process that automatically extracted the product names, reference codes, and prices from the PDF.

Integrating with Sanity CMS

With the product data now validated and enriched, it was time to push everything into Sanity CMS. I used the Sanity client’s .createIfNotExists() method to create product records only if they didn’t already exist. This method helped me avoid creating duplicates and ensured that I was always working with the most up-to-date product information.

const sanityClient = require('@sanity/client')

const client = sanityClient({
  projectId: 'your-project-id',
  dataset: 'production',
  token: 'your-token',
  useCdn: true
})

async function createProductInSanity(product) {
  try {
    // there were a lot more fields but you get idea
    await client.createIfNotExists({
      name: product.name,
      productDescription: product.description,
      productImage: product.image
    })
  } catch (error) {
    console.error('Error creating product in Sanity:', error)
  }
}

However, I needed to make sure the Sanity mutations didn’t overload the server with too many requests. To address this, I used p-limit, a small library that limits the number of concurrent promises, ensuring I didn’t hit the rate limits.

const pLimit = require('p-limit')
const limit = pLimit(5) // Limit to 5 concurrent requests

const productPromises = products.map((product) =>
  limit(() => createProductInSanity(product))
)

await Promise.all(productPromises)

Sanity CMS

To make the process smoother for the client—the final user—I created a couple of Sanity Actions to streamline product management. One of these actions allows for manual scraping directly within the product document in Sanity CMS.

export function findInfo(context) {
  const client = context.getClient({ apiVersion: '2022-11-29' })

  const asyncFindInfo = (props) => {
    const { published, draft } = props
    // in case the product is not published
    const slug = draft ? draft.slug : published ? published.slug : null

    return {
      label: 'Buscar Información',
      onHandle: async () => {
        try {
          if (!slug) {
            toast.error('Error: you must have a slug') // toast from sooner ❤
            return
          }

          const product = await fetch(
            `https://cors-anywhere.herokuapp.com/https://apple.com/${slug.current}/` // just kidding, ist not apple 🤣
          )

          await createProductInSanity(product)
        } catch (error) {
          toast.error('Error with scraping process')
        }
      }
    }
  }

  return asyncFindInfo
}

Integrating with Sanity CMS was simple and straightforward, making it easy to structure and manage the imported product data efficiently.

const defineConfig = require('sanity').defineConfig
const findInfo = require('./sanity/lib/actions').findInfo

export default defineConfig({
  // ... All the other config
  document: {
    actions: (prev, context) => {
      // if the document is of type product then add the action
      if (context.schemaType === 'product') {
        return [...prev, findInfo(context)]
      }
      return prev
    }
  }
})

and Voila!

Automation

With the product data now successfully imported into Sanity CMS, I turned my attention to automating the entire process. To make sure the product catalog stayed up-to-date, I set up a cron job to run daily at 00:01 AM (its a good time to have server idle). This cron job would fetch the latest products from the WordPress API and automatically update the Sanity CMS.

const cron = require('node-cron')
const pLimit = require('p-limit')

const limit = pLimit(5) // Adjust the concurrency limit

cron.schedule('0 1 * * *', async () => {
  try {
    const wpProducts = await fetchAllProductLinks() // Fetch WordPress product links
    const sanityProducts = await client.fetch(`*[_type == "product"]{ name }`)

    // Filter out products that are already in Sanity
    const newProducts = wpProducts.filter(
      (product) =>
        !sanityProducts.some(
          (sanityProduct) => sanityProduct.name === product.name
        )
    )

    if (newProducts.length === 0) {
      return
    }

    // Scrape and create products with concurrency control
    await Promise.all(
      newProducts.map((product) =>
        limit(async () => {
          try {
            const details = await scrapeProductDetails(product)
            await createProductInSanity(details)
          } catch (err) {
            console.error(`❌ Error creating product: ${product.name}`, err)
          }
        })
      )
    )
  } catch (err) {
    console.error('❌ Cron job failed:', err)
  }
})

I also set up email notifications to alert the client whenever new products were added (using Resend). This way, they always knew when the product catalog was updated without having to manually check.

Conclusion

This project was a great example of how automation and smart integrations can dramatically improve the efficiency of product management for e-commerce websites. By combining Cheerio for scraping, Sanity CMS for content management, and Heroku CORS Anywhere to bypass CORS issues, I was able to create a streamlined process that kept the client’s product catalog up-to-date without requiring constant manual intervention.

TinaCMS: A Headless CMS with Git Version Control

N4N1T0 — Fri, 21 Feb 2025 08:58:24 +0000

In the realm of web development, Content Management Systems (CMS) have undergone significant evolution to meet the demands for flexibility, scalability, and modern workflows.

TinaCMS has emerged as a standout open-source, headless CMS that integrates seamlessly with Git, providing developers with complete control over content through an efficient versioning system.

What is TinaCMS?

TinaCMS is a content management system designed to integrate effortlessly into modern web applications. Unlike traditional CMS platforms that rely on centralized databases, TinaCMS manages content directly within Markdown and JSON files stored in a Git repository. This approach enhances collaboration, version control, and continuous deployment.

Benefits of Using TinaCMS

Integration with Git

By treating content as code, TinaCMS ensures that every modification is tracked within a version control system, offering:

A detailed history of changes.
Easy reversion to previous versions.
A collaborative workflow featuring reviews and pull requests.

Headless and Flexible Architecture

As a headless CMS, TinaCMS decouples the content management layer from the frontend, allowing developers to utilize frameworks like Next.js, Nuxt.js, or others. This separation ensures a decoupled and optimized architecture.

Live Editing Experience

TinaCMS offers a live editing experience within the application itself, eliminating the need for external interfaces to manage content. This feature enhances productivity and user experience.

Open Source and Extensible

Being open-source, TinaCMS encourages customization and community contributions. Its flexible API facilitates integration with various platforms and supports custom use cases.

Use Cases

Blogs and Static Sites: Ideal for developers seeking full control over content without the complexities of databases.
Technical Documentation: With native Markdown support, it's perfect for managing documentation within Git repositories.
Lightweight E-commerce: Suitable for managing product descriptions and dynamic content in online stores built with modern frameworks.

Special Considerations for Astro Developers

Astro developers can seamlessly integrate TinaCMS into their projects to enhance content management capabilities. Here's how to get started:

1. Initialize TinaCMS in Your Astro Project

Navigate to your project's root directory and run:

npx @tinacms/cli@latest init

During setup, when prompted for the "public assets directory," press Enter to accept the default (public).

2. Configure the CMS

Modify the package.json to update the dev script:

{
  "scripts": {
    "dev": "tinacms dev -c \"astro dev\""
  }
}

3. Define Content Models

Edit the .tina/config.ts file to model your content. For example, to add a "posts" collection:

import { defineConfig } from "tinacms";

export default defineConfig({
  branch: 'main',
  clientId: null,
  token: null,
  build: {
    outputFolder: "admin",
    publicFolder: "public",
  },
  media: {
    tina: {
      mediaRoot: "images",
      publicFolder: "public",
    },
  },
  schema: {
    collections: [
      {
        name: "posts",
        label: "Posts",
        path: "src/content/posts",
        format: 'mdx',
        fields: [
          {
            type: "string",
            name: "title",
            label: "Title",
            isTitle: true,
            required: true,
          },
          {
            type: "datetime",
            name: "posted",
            label: "Date Posted",
            required: true,
          },
          {
            type: "rich-text",
            name: "body",
            label: "Body",
            isBody: true,
          },
        ],
      },
    ],
  },
});

4. Start TinaCMS

Run the development server:

npm run dev

Access the TinaCMS admin interface at http://localhost:3000/admin/index.html.

By following these steps, Astro developers can enhance their projects with a robust and flexible content management system, streamlining both development and content editing processes.

For more detailed information, refer to the Astro + Tina Setup Guide.

Conclusion

TinaCMS offers a powerful and modern solution for content management in web applications. Its Git integration, headless architecture, and live editing capabilities make it an excellent choice for developers seeking flexibility and control. Whether you're building a blog, managing technical documentation, or developing an e-commerce platform, TinaCMS provides the tools necessary for efficient content management.

Introduction to Redsys Integration with Next.js 15

N4N1T0 — Wed, 12 Feb 2025 08:12:20 +0000

Nowadays, everyone is trying to make money online—whether through a SaaS, an eCommerce store, or other types of web applications. While global payment processors like Stripe and PayPal are common, different countries have their own preferred payment platforms.

In Spain, practically all online banking transactions go through Redsys, a SOAP-based API platform designed to make digital payments within the Spanish banking network easier and more secure. While Redsys is powerful, it can also be challenging to manage and deploy due to its unique integration requirements.

In this tutorial, we will use Next.js 15 and Server Actions to create a fast and efficient redirect-based payment flow with Redsys. By the end, you’ll have a functional implementation that allows customers to complete payments through Redsys with minimal setup.

Setting Up Next.js 15 and Installing Redsys-Easy

To get started, we need to set up a new Next.js 15 project and install the necessary dependencies.

1. Initialize a Next.js 15 Project

Run the following command to create a new Next.js 15 application:

npx create-next-app@latest my-redsys-project
cd my-redsys-project

2. Install Dependencies

Next, install redsys-easy to handle Redsys payment requests and responses:

npm install redsys-easy

With this setup complete, we can now move on to implementing the payment flow!

Configuring Environment Variables

Before implementing the payment flow, we need to securely store our sensitive credentials provided by the bank or client. Create a .env.local file in the root of your project and add the following variables:

REDSYS_MERCHANT_CODE=
REDSYS_TERMINAL=
REDSYS_SECRET_KEY=

Make sure not to prefix these variables with NEXT_PUBLIC_ as they must remain secure on the server side.

Creating the Redsys Client

There are multiple ways to interact with the Redsys API, but for now, we will use the redirect form method. This approach generates an HTML form that redirects users to a secure payment gateway hosted by Redsys, ensuring safe transactions.

Create a new file src/lib/redsys.ts and add the following:

import { createRedsysAPI, SANDBOX_URLS, PRODUCTION_URLS } from 'redsys-easy'

export const { createRedirectForm, processRestNotification } = createRedsysAPI({
  secretKey: process.env.REDSYS_SECRET_KEY!,
  urls: SANDBOX_URLS
})

Although we are currently using the SANDBOX_URLS for development, the redsys-easy package also includes the PRODUCTION_URL variable, which will be used when we go live. For now, we'll stick with the sandbox environment during development.

createRedirectForm: Generates a form that redirects users to the Redsys payment gateway.
processRestNotification: This will be used later to handle payment notifications from Redsys.

Creating a Server Action for Payments

We will store our Server Actions inside the src/actions folder. For now, let's create a simple Server Action to prepare the payment request.

1. Create the Server Action File

Inside src/actions, create a new file called payment.ts and add the following code:

'use server'

import {
  CURRENCIES,
  TRANSACTION_TYPES,
  randomTransactionId,
  LANGUAGES
} from 'redsys-easy'
import { createRedirectForm } from '@/lib/clients'

export async function initiatePayment(orderId: string, amount: number) {}

2. Add Constants

Now, we'll define some variables and constants to populate the redirect form with the most accurate information possible. Here, we add the necessary environment variables.

'use server'

import { CURRENCIES, TRANSACTION_TYPES, randomTransactionId } from 'redsys-easy'
import { createRedirectForm } from '@/lib/clients'

const merchantInfo = {
  DS_MERCHANT_MERCHANTCODE: process.env.REDSYS_MERCHANT_CODE!, // Merchant code
  DS_MERCHANT_TERMINAL: process.env.REDSYS_TERMINAL!, // Terminal number
  DS_MERCHANT_TRANSACTIONTYPE: TRANSACTION_TYPES.AUTHORIZATION // '0' = Authorization
}

3. Helper Functions and Variables

Next, we need to specify the total amount as a decimal number so that the Redsys server can process it. We also need to extract the code for the "EUR" currency from the CURRENCIES object used by Redsys.

'use server'
// ... other imports

import Decimal from 'decimal.js'

export async function initiatePayment(orderId: string, amount: number) {
  const currencyInfo = CURRENCIES['EUR']
  const redsysAmount = new Decimal(amount)
    .mul(10 ** currencyInfo.decimals)
    .toFixed(0)
  const redsysCurrency = currencyInfo.num
}

4. Create the Form and Return

Now, we create the form to use on the frontend. The DS_MERCHANT_URL variables are very important as they determine where the user will be redirected after the payment—either to a success page (OK) or an error page (KO). Redsys will append a code to the URL, which you can use to verify the request.

export async function initiatePayment(orderId: string, amount: number) {
  const currencyInfo = CURRENCIES['EUR']
  const redsysAmount = new Decimal(amount)
    .mul(10 ** currencyInfo.decimals)
    .toFixed(0)
  const redsysCurrency = currencyInfo.num

  const form = createRedirectForm({
    ...merchantInfo,
    DS_MERCHANT_ORDER: orderId,
    DS_MERCHANT_AMOUNT: redsysAmount,
    DS_MERCHANT_CURRENCY: redsysCurrency,
    DS_MERCHANT_URLOK: `${process.env.NEXT_PUBLIC_URL}/exito`,
    DS_MERCHANT_URLKO: `${process.env.NEXT_PUBLIC_URL}/fallo`,
    DS_MERCHANT_TRANSACTIONDATE: new Date().toISOString()
  })

  return form
}

Now on the Frontend

1. Obtain the Redirect Form

You can create a simple form attached to the checkout to trigger the server action and obtain the redirectForm from the server action.

import { initiatePayment } from '@/actions'

const CheckoutForm = () => {
  const handleSubmit = async (e: FormEvent<HTMLFormElement>) => {
    e.preventDefault()
    const formData = new FormData(e.target as HTMLFormElement)

    const orderId = formData.get('orderId') as string
    const amount = Number(formData.get('amount')) as number

    const redirectForm = await initiatePayment(orderId, amount)
    console.log(redirectForm)
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type='text' placeholder='Order ID' required />
      <input type='number' placeholder='Amount' required />
      <button type='submit'>Proceed to Payment</button>
    </form>
  )
}

2. The Tricky Part

For the fun part, you need to store the data returned from the server action in a blank form component. This form must include three specific inputs: Ds_SignatureVersion, Ds_MerchantParameters, and Ds_Signature. These inputs will receive values from the redirectForm.body object. Once the form is completed, it will automatically submit and make a request to the URL provided by the Redsys server, redirecting the user to the payment gateway page.

const CheckoutForm = () => {
  const [paymentForm, setPaymentForm] = React.useState<RedirectForm | null>(
    null
  )

  // Handle form logic and update paymentForm state here (not shown for brevity)

  return (
    <>
      {/* Initial form here */}
      <PaymentForm form={paymentForm} />
    </>
  )
}

const PaymentForm = ({ form }: { form: RedirectForm | null }) => {
  const formRef = React.useRef<HTMLFormElement | null>(null)

  React.useEffect(() => {
    // Automatically submit the form when the component mounts
    if (formRef.current && form) {
      formRef.current.submit()
    }
  }, [form])

  if (!form) {
    return null
  }

  return (
    <form id='paymentForm' ref={formRef} action={form?.url} method='POST'>
      <input
        type='hidden'
        name='Ds_SignatureVersion'
        value={form?.body.Ds_SignatureVersion}
      />
      <input
        type='hidden'
        name='Ds_MerchantParameters'
        value={form?.body.Ds_MerchantParameters}
      />
      <input
        type='hidden'
        name='Ds_Signature'
        value={form?.body.Ds_Signature}
      />
    </form>
  )
}

Conclusion

In this tutorial, we've successfully integrated Redsys with Next.js 15 to create a streamlined payment flow using the redirect form method. By leveraging the power of Server Actions, we efficiently generate the necessary payment form and automatically redirect the user to the Redsys payment gateway.

You now have a functional implementation of a secure payment gateway that can be customized further with additional parameters like merchant information, language, and transaction types. Once the user completes the payment, the server will handle the response for either a successful or failed transaction.

This integration allows businesses operating in Spain to easily implement Redsys as their payment solution, ensuring secure and efficient transactions.

What's Next?

Stay tuned for the next update, where I'll share a couple of tricks to improve this flow, enhance performance, and make the integration even smoother for production environments. Keep an eye out for the upcoming enhancements!

Footnote

A special thanks to Javier Tury for the redsys-easy package, which greatly simplifies the integration of Redsys with Node.js and Next.js applications.

DEV Community: N4N1T0

Use Claude Code with Any Model via OpenRouter

OpenRouter as the gateway

The environment variables

The orclaude script

A native orclaude command in PowerShell

macOS and Linux

Why the split matters

Astro 5: What Changed and Why It Matters for SEO

What Astro actually changes

Content Layer

Server islands

astro:env

The SEO question

When a SPA is still the right call

Upgrading from Astro 4

How I use it here

Astro Actions and Vanilla JavaScript for Forms

🗂️ Frontmatter vs Client-Side Scripts in Astro

Example: Contact Form in Astro

1️⃣ Frontmatter (Server-Side Only)

2️⃣ The Markup (HTML + Components)

3️⃣ Client-Side Script (DOM Manipulation)

⚠️ Don't Forget SSR

✅ Why I Like This Approach

Conclusion

Automate Your Product Feed in Google Merchant Center with Node.js

🧱 Step 1: Authenticate with a Service Account

🔑 What is a Service Account?

✅ How to create one

🔐 Keep it secure

🔒 Authenticate with GoogleAuth

🧩 Step 2: Insert or Update Products

🛠️ Example Function

🔁 Step 3: Run Controlled Synchronization

⚙️ Example

🎁 Bonus: Automate with a Daily Cron Job

🚀 Conclusion

Search and AI: The Dream Team for an eCommerce Revenue Boost

🧩 The Challenge: UX That Converts for Niche eCommerce

🚀 The Stack: Orama.search + OpenAI + Sanity

🔄 Dynamic Product Updates (Sanity + Cron + GROQ)

🔍 The Search Page: UX Meets Relevance

🎯 CRO Techniques Enabled

🧠 Why Orama Over Meilisearch/Typesense/Algolia?

🔮 What’s Next: AI Chatbot Integration

Integrating Redsys with Next.js 15 – Part 2

Handling Payment Notifications Efficiently

The Challenge: Asynchronous Bank Processes

Creating the Notification API

Improving Performance with URL Parameters

Implementing a Payment Logic Function

Conclusion

How to Scrap Product for E-commerce with Sanity CMS and Cheerio

Introduction

Scraping the Data

Validating and Enriching the Data

Integrating with Sanity CMS

Sanity CMS

Automation

Conclusion

TinaCMS: A Headless CMS with Git Version Control

What is TinaCMS?

Benefits of Using TinaCMS

Use Cases

Special Considerations for Astro Developers

1. Initialize TinaCMS in Your Astro Project

2. Configure the CMS

3. Define Content Models

4. Start TinaCMS

Conclusion

Introduction to Redsys Integration with Next.js 15

Setting Up Next.js 15 and Installing Redsys-Easy

1. Initialize a Next.js 15 Project

2. Install Dependencies

Configuring Environment Variables

Creating the Redsys Client

Creating a Server Action for Payments

1. Create the Server Action File

2. Add Constants

The `orclaude` script

A native `orclaude` command in PowerShell

`astro:env`