Cómo llamar a APIs externas desde Webflow sin exponer tus claves de API

Traer datos externos a un sitio de Webflow es la parte fácil. Mantener tus credenciales de API fuera del navegador es donde la mayoría de las implementaciones fallan.

El problema es llamar a APIs sin exponer las credenciales en el navegador. He visto este error más veces de las que me gustaría: una clave de API dentro de una llamada fetch() del lado del cliente, visible para cualquiera que abra las herramientas de desarrollo del navegador.

Es un agujero de seguridad que se puede explotar fácilmente y que es igual de fácil de evitar una vez que entiendes los tres patrones de integración de Webflow.

Esta guía cubre los tres patrones con código funcional para cada uno y profundiza en el proxy de Webflow Cloud, el único enfoque que mantiene las credenciales totalmente fuera del navegador.

3 formas de integrar APIs externas con Webflow

El método de integración adecuado depende de dos preguntas: ¿tu API requiere autenticación y necesitas mostrar datos en tiempo real en el navegador?

Cada enfoque maneja esto de manera diferente:

Aquí tienes cómo elegir.

Método n.º 1: Proxy de API de Webflow Cloud (recomendado para API autenticadas)

Webflow Cloud te permite desplegar una aplicación Next.js, Astro o Vite junto a tu sitio de Webflow en el mismo dominio. Una ruta de API en esa aplicación actúa como proxy: tu página de Webflow llama al proxy, el proxy llama a la API externa desde el servidor y solo la respuesta limpia llega al navegador. La clave API nunca sale del servidor.

Este es el único enfoque que utilizo para sitios en producción con API autenticadas. La ventaja de seguridad es evidente, pero el patrón de proxy va más allá. Puedes dar forma a la respuesta (eliminar campos que no necesitas antes de que viajen por la red), implementar una caché para no saturar la API externa en cada carga de página y cambiar de proveedor de API más adelante sin tocar tu código frontend.

El inconveniente: Webflow Cloud requiere Node.js 22 o superior, una cuenta de GitHub y un repositorio desde el cual desplegar. La configuración inicial lleva unos 30 minutos.

Método n.º 2: Code Embed + fetch del lado del cliente (solo API públicas)

Si la API a la que llamas es realmente pública (no requiere autenticación, o la autenticación está diseñada explícitamente para ser visible), puedes llamarla directamente desde un elemento Code Embed usando fetch()fetch. No se necesita Webflow Cloud ni backend, aunque el elemento Code Embed en sí requiere un espacio de trabajo Core, Growth, Agency o Freelancer, o un plan de sitio activo.

La advertencia es absoluta: si la API requiere una clave, no uses este enfoque. Cada URL y encabezado que envía tu página es visible en las herramientas de desarrollo del navegador, incluidas las credenciales integradas en el JavaScript del lado del cliente.

He tenido clientes que han acudido a mí tras recibir facturas de miles de dólares por exceso de uso de API porque un competidor encontró y utilizó su clave expuesta. Solo se necesitan unos 30 segundos con las herramientas de desarrollo abiertas.

Buenos casos de uso para fetch del lado del cliente: conjuntos de datos gubernamentales públicos, API meteorológicas abiertas sin autenticación y endpoints que hayas diseñado a propósito para ser accesibles públicamente. Si hay una clave de por medio, pasa al Método 1.

Método n.º 3: Automatización sin código con Zapier e integraciones nativas (solo basado en eventos)

Zapier y la biblioteca de integraciones nativas de Webflow conectan Webflow con servicios externos sin necesidad de código personalizado. El envío de un formulario de Webflow activa un Zap que envía datos a Salesforce, Airtable, HubSpot o cientos de otras herramientas; todo configurado a través de un panel de control, no de un editor de código.

Este enfoque funciona para flujos de trabajo basados en eventos: algo sucede (por ejemplo, se envía un formulario o se publica un elemento del CMS) y los datos fluyen hacia un sistema externo. No sirve para mostrar datos externos en tiempo real en tus páginas de Webflow.

Si necesitas que un feed de precios, un recuento de inventario o datos específicos de un usuario aparezcan en el navegador, necesitas el Método 1 o el Método 2. El Método 3 es unidireccional y asíncrono por diseño. Es una tubería de datos, no una fuente de datos para tu frontend.

¿Qué necesitas para integrar una API externa con Webflow?

Los requisitos previos dependen del método que utilices. Para el enfoque de proxy de Webflow Cloud (que maneja la mayor variedad de casos, incluidas las API que requieren autenticación), necesitas tener cuatro cosas listas antes de empezar.

Verifica todo esto antes de ejecutar la CLI.

Credenciales de la API externa y documentación del endpoint

Antes de escribir una sola línea de código de proxy, obtén tu clave de API y lee la documentación de autenticación de tu API específica. Cada API maneja las credenciales de forma diferente: algunas piden un Authorization: Bearer <key> header, otras usan x-api-key, algunas incrustan la clave en la ruta de la URL.

El código de proxy que escribas depende totalmente de lo que espere la API, así que este paso no es opcional.

Revisa los límites de tasa y los precios antes de crear una estrategia de caché. Si la API permite 1000 llamadas al día gratis y tu sitio recibe 5000 visitantes, un caché de diez minutos te mantendrá muy por debajo del límite.

Si se factura por llamada sin un nivel gratuito, el caché es fundamental; cada solicitud no almacenada en caché es facturable. He visto un entorno de pruebas con pruebas de carga agresivas y sin caché generar una factura de API de 400 dólares en dos horas. Lee la página de precios antes de implementar nada.

Una cuenta de Webflow y una decisión sobre dónde residirá la aplicación

No necesitas necesariamente un sitio existente. Las aplicaciones de Webflow Cloud se implementan vinculadas a un sitio, donde la aplicación se monta en una ruta del dominio de ese sitio, o de forma independiente en su propio dominio, sin involucrar a ningún sitio. Ambos métodos son compatibles y el alojamiento de aplicaciones está incluido en todos los niveles, incluido el plan Starter gratuito, por lo que un plan de sitio de pago no es la barrera que la gente supone.

Esta guía sigue la ruta vinculada al sitio, porque un proxy suele ser más útil en el mismo dominio que las páginas que lo llaman. Configurar /app como la ruta de montaje significa que tus rutas de API residen en mysite.webflow.io/app/api/your-route, con el mismo origen que tus páginas, lo cual elimina el problema de CORS por completo.

El sitio debe publicarse al menos una vez antes de que tu entorno de Webflow Cloud esté activo. Si ves un error 404 en tu ruta de montaje después de una implementación exitosa, publicar tu sitio de Webflow activará la ruta en la capa de enrutamiento de Webflow, especialmente durante la configuración inicial.

El entorno está configurado, pero la ruta de montaje no está activa hasta que Webflow lo publica.

Cuenta y repositorio de GitHub

Webflow Cloud se implementa desde un repositorio de GitHub. Cada envío (push) a tu rama configurada activa automáticamente una nueva compilación e implementación. Necesitas una cuenta de GitHub y un repositorio para tu aplicación antes de poder crear un proyecto de Webflow Cloud.

El paso de instalación de la aplicación de GitHub en la configuración de Webflow Cloud es obligatorio. Webflow necesita acceso de lectura al repositorio para extraer y compilar tu código. Si las implementaciones dejan de activarse después de cambiar la configuración de GitHub o mover un repositorio, revisa esto primero.

Ve a la configuración del sitio, abre la barra lateral de Webflow Cloud y haz clic en "Install GitHub" para verificar que Webflow Cloud aún tenga acceso a tu repositorio.

Node.js 22 o posterior y npm

Webflow Cloud requiere Node.js 22 o superior, y la CLI de Webflow eleva el requisito mínimo a 22.13.0, así que asegúrate de cumplir con esa versión en lugar del mínimo de la plataforma. Comprueba tu versión con node --version antes de inicializar un proyecto y actualízala a través de nodejs.org o un gestor de versiones como nvm si es necesario.

Ten en cuenta también que npm es actualmente el único gestor de paquetes que Webflow Cloud admite para la compilación

La CLI de Webflow utiliza npm como gestor de paquetes. Yarn y pnpm no son compatibles en este momento.

Instala la CLI de forma global una vez que hayas confirmado tu versión de Node:

npm install -g @webflow/webflow-cli

Ejecuta webflow --version para confirmar que la instalación se realizó correctamente. Si no se encuentra el comando, es posible que la ruta de instalación global no esté en tu PATH; un problema común en macOS con ciertos gestores de versiones de Node.

5 pasos para crear un proxy de API con Webflow Cloud

El proxy de Webflow Cloud es una ruta de API de Next.js o Astro que llama a tu API externa desde el lado del servidor, opcionalmente da formato y almacena en caché la respuesta, y devuelve solo lo que tu frontend necesita. Este enfoque oculta las credenciales, reduce las llamadas innecesarias a la API y desacopla por completo tu frontend del proveedor de API externo.

Aquí tienes la configuración completa.

1. Inicializa tu proyecto de Webflow Cloud

Ejecuta webflow cloud init en tu terminal. La pregunta más importante es la primera, y es la que la mayoría de las guías pasan por alto: "¿Dónde quieres desplegar esta aplicación?" La opción predeterminada es Nuevo dominio, que crea una aplicación independiente en su propio dominio, montada en /.

Elige Sitio existente en su lugar. Todo lo que sigue en esta guía asume una aplicación vinculada a un sitio: el panel de Webflow Cloud dentro de la configuración de ese sitio, URLs como mysite.webflow.io/app/api/data, y el paso de Publicar en el Diseñador. Si aceptas la opción predeterminada, nada de eso se aplicará, lo cual es una situación confusa en la que terminar después de diez minutos de trabajo.

Las preguntas restantes cubren el framework (Next.js, Astro o Vite), el nombre de la aplicación, la ruta de montaje (por ejemplo, /app), la autenticación con tu cuenta de Webflow y la búsqueda del sitio al que vincularla.

Una nota sobre los nombres: cloud init y cloud deploy todavía funcionan, pero Webflow ahora trata el espacio de nombres apps como canónico y documenta los anteriores como alias obsoletos que generan advertencias. En el momento de escribir esto, apps solo está disponible en el canal de pre-lanzamiento de la CLI, por lo que cloud sigue siendo la opción funcional en una instalación estándar.

webflow cloud init

Tras la inicialización, la CLI crea un directorio de proyecto con la estructura base e importa tu sistema de diseño de Webflow mediante DevLink.

Entra en el directorio e inicializa un repositorio de git:

cd your-project-name
git init

Envía el repositorio a GitHub. Una vez allí, ve a la configuración de tu sitio en Webflow y selecciona "Webflow Cloud" en la barra lateral. Haz clic en "Login to GitHub" y luego en "Install GitHub" para otorgar a Webflow Cloud acceso a tus repositorios.

Con GitHub conectado, haz clic en "Create New Project", introduce el nombre de tu proyecto y la URL del repositorio de GitHub, y luego haz clic en "Create project". A continuación, haz clic en "Create environment" y configura la rama desde la que realizar el despliegue y la ruta de montaje. Por último, haz clic en "Publish" en tu Diseñador o Panel de control de Webflow.

La mayoría de la gente olvida ese paso de publicación. La ruta de montaje solo se activa después de publicar. Sin hacerlo, obtendrás un error 404 en la URL de tu proxy.

2. Crea la ruta de la API

En tu proyecto inicializado, crea el archivo de ruta de la API. La ubicación depende de tu framework.

Para Astro, crea src/pages/api/data.ts. Para Next.js, crea app/api/data/route.ts.

Ninguno de los dos frameworks necesita una declaración de tiempo de ejecución aquí, y añadirla es la forma más común de romper estas rutas.

Para Next.js, no añadas export const runtime = "edge". Webflow Cloud compila las aplicaciones de Next.js con el adaptador OpenNext Cloudflare, y su guía de configuración indica eliminar esa línea de todos los archivos fuente porque no es compatible con el tiempo de ejecución Edge de Next.js. Los Route Handlers deben permanecer en el tiempo de ejecución de Node.js, que es el predeterminado y el que expone las API de Node que proporciona el tiempo de ejecución de Workers.

Para Astro, tampoco añadas export const config = { runtime: "edge" } . Astro no tiene esa exportación de ruta: su exportación a nivel de ruta documentada es export const prerender, y los propios ejemplos de Astro de Webflow para enlaces de almacenamiento no incluyen ninguna declaración de tiempo de ejecución.

Webflow Cloud instala y configura el adaptador por ti, y su guía de configuración dice claramente que "no necesitas añadir un adaptador, una ruta base o un modo de salida".

Ten en cuenta que la página de bring-your-own-app de Webflow todavía sugiere añadir una directiva edge a las rutas de API para ambos frameworks. Ese consejo es anterior a la canalización de compilación actual; sigue el adaptador que realmente compila tu aplicación.

Para Astro:

// src/pages/api/data.ts
export async function GET({ locals }: any) {
    const env = locals.runtime.env;
    const API_KEY = env.MY_API_KEY || process.env.MY_API_KEY;

    if (!API_KEY) {
        return new Response(
            JSON.stringify({ error: 'Server configuration error' }),
            { status: 500, headers: { 'Content-Type': 'application/json' } }
        );
    }

    const response = await fetch(`https://api.example.com/endpoint?key=${API_KEY}`);

    if (!response.ok) {
        return new Response(
            JSON.stringify({ error: 'External API request failed' }),
            { status: response.status, headers: { 'Content-Type': 'application/json' } }
        );
    }

    const data = await response.json();
    return new Response(JSON.stringify(data), {
        headers: { 'Content-Type': 'application/json' }
    });
}

Para Next.js:

// app/api/data/route.ts
export async function GET(request: Request) {
    const apiKey = process.env.MY_API_KEY;

    if (!apiKey) {
        return Response.json({ error: 'Server configuration error' }, { status: 500 });
    }

    const response = await fetch(`https://api.example.com/endpoint?key=${apiKey}`);

    if (!response.ok) {
        return Response.json({ error: 'External API request failed' }, { status: response.status });
    }

    const data = await response.json();
    return Response.json(data);
}

Ambos patrones hacen lo mismo: recuperar la clave de API de las variables de entorno del lado del servidor, llamar a la API externa y devolver la respuesta. El valor MY_API_KEY nunca se envía al navegador. Sustituye la URL fetch y cualquier encabezado por lo que requiera tu API específica.

Ninguno de los fragmentos declara un tiempo de ejecución, y esto es intencionado. Si has visto una versión de este patrón que lo hace, fue escrita para una canalización de compilación anterior.

3. Añade tu clave de API como variable de entorno

En Webflow, navega a la configuración del sitio (Site Settings) y abre la barra lateral de Webflow Cloud. Selecciona tu proyecto y abre el entorno que acabas de crear.

Busca la sección de variables de entorno y añade una nueva variable:

• Nombre: MY_API_KEY
• Valor: tu clave de API real

Los nombres de las variables distinguen entre mayúsculas y minúsculas. MY_API_KEY y my_api_key son variables diferentes, y la discrepancia no produce un error. Tu código simplemente lee undefined, y la llamada a la API falla silenciosamente. Después de añadir cualquier variable, vuelve a desplegar la aplicación. Las variables añadidas después del último despliegue no estarán disponibles hasta que se ejecute la siguiente compilación.

Para el desarrollo local, crea un archivo .env en la raíz del proyecto y añade la clave allí. La CLI rellena un archivo .env durante Webflow auth login, así que es posible que ya lo tengas. Nunca subas .env a GitHub.

4. Llama al proxy desde tu página de Webflow

Con la ruta de la API desplegada, llámala desde tu página de Webflow usando un elemento Code Embed. La ruta debe incluir tu prefijo de montaje: /app/api/data en lugar de /api/data. Sigue siendo una ruta relativa a la raíz, así que esto se refiere al prefijo y no a si las URL son relativas o absolutas.

Dentro de una aplicación Next.js, lee el prefijo en tiempo de ejecución en lugar de codificarlo, ya que Webflow Cloud lo establece a partir de la ruta de montaje de tu entorno:

const baseUrl = process.env.NEXT_PUBLIC_BASE_PATH ?? '';
const response = await fetch(`${baseUrl}/api/data`);

En un Code Embed en una página de Webflow, no tienes acceso a esa variable, por lo que el prefijo literal está bien ahí. Solo recuerda actualizarlo si alguna vez vuelves a montar el entorno.

Añade un elemento Code Embed a tu página de Webflow:

<div id="api-output">Loading...</div>

<script>
  async function loadData() {
    try {
      const response = await fetch('/app/api/data');
      if (!response.ok) throw new Error('Request failed');
      const data = await response.json();
      document.getElementById('api-output').textContent = JSON.stringify(data, null, 2);
    } catch (error) {
      document.getElementById('api-output').textContent = 'Error loading data.';
    }
  }

  loadData();
</script>

Reemplaza con tu ruta de montaje y nombre de ruta. Si tu ruta de montaje es y tu archivo de ruta es , la URL de fetch es . Equivocarse con esta ruta es una de las razones más comunes por las que la llamada devuelve un error 404 en producción, a pesar de funcionar perfectamente en el entorno de desarrollo local./app/api/data/feedsapi/prices.ts/feeds/api/prices

Publica tu sitio de Webflow después de añadir el Code Embed. Los scripts dentro de un Code Embed se renderizan en los modos de vista previa y comentarios para que puedas comprobar la llamada allí; publicar solo cambia si el comportamiento está activo para los visitantes.

Si quieres excluir código específicamente de la vista previa, Webflow permite envolverlo en un comentario , que solo existe porque la ejecución en vista previa es el comportamiento predeterminado.EXCLUDE FROM PREVIEW

5. Añade caché de respuesta con KV Store

Sin caché, cada carga de página que llama a tu proxy activa una nueva solicitud a la API externa. Para una página con muchas lecturas, esto suma rápidamente. Si muestras los mismos datos a todo el mundo y estos solo cambian una vez por hora, no hay razón para hacer una llamada a la API externa por cada visitante.

Primero, declara un binding de KV Store en tu archivo en la raíz del proyecto:wrangler.json

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-app",
  "compatibility_date": "2025-04-15",
  "kv_namespaces": [
    {
      "binding": "CACHE_KV",
      "id": "placeholder"
    }
  ]
}

Los campos y no son decorativos. Webflow Cloud valida este archivo antes de leer tus bindings, y un fallo de validación no detiene la compilación; registra el error y despliega tu aplicación sin ningún binding .namecompatibility_date

Obtienes un despliegue exitoso y un binding en tiempo de ejecución, lo que se manifiesta como un error de búsqueda en caché en lugar de un error de configuración. Si los bindings parecen faltar en un entorno desplegado, lee el registro de compilación antes de tocar nada más.undefined

El puede seguir siendo un marcador de posición. Webflow Cloud aprovisiona el espacio de nombres por entorno y sustituye el ID real en el momento del despliegue; el nombre del binding debe coincidir con lo que lee tu código. Tras el despliegue, la pestaña de almacenamiento en el panel de control de tu entorno muestra el binding y su estado.id

Luego, actualiza tu ruta de API para comprobar la caché antes de llamar a la API externa:

// Astro — src/pages/api/data.ts with caching
export async function GET({ locals }: any) {
    const env = locals.runtime.env;
    const API_KEY = env.MY_API_KEY;
    const kv = env.CACHE_KV;

    if (!API_KEY) {
        return Response.json({ error: 'Server configuration error' }, { status: 500 });
    }

    // Check cache first
    const cached = await kv.get('api_response');
    if (cached) {
        return new Response(cached, {
            headers: { 'Content-Type': 'application/json', 'X-Cache': 'HIT' }
        });
    }

    try {
        const response = await fetch(`https://api.example.com/endpoint?key=${API_KEY}`);

        // Check before caching. Without this, one upstream 429 or 500
        // gets JSON-parsed and written to KV, and you serve that error
        // to every visitor for the full TTL.
        if (!response.ok) {
            return Response.json(
                { error: 'External API request failed' },
                { status: response.status }
            );
        }

        const data = await response.json();

        await kv.put('api_response', JSON.stringify(data), { expirationTtl: 600 });

        return new Response(JSON.stringify(data), {
            headers: { 'Content-Type': 'application/json', 'X-Cache': 'MISS' }
        });
    } catch (error) {
        // A non-JSON error body makes response.json() throw. Without
        // the catch that surfaces as an unhandled 500 with no shape.
        console.error('Proxy error:', error);
        return Response.json({ error: 'Upstream request failed' }, { status: 502 });
    }
}

Ten en cuenta que las protecciones del paso 2 siguen aquí. La caché es donde más importan: una respuesta de error no controlada no solo falla una solicitud; se escribe en KV y se sirve a todos durante los siguientes diez minutos.

Para Next.js, la estructura es la misma, pero accedes al binding de forma diferente. No hay ; obtienes el contexto de Cloudflare desde el adaptador:locals.runtime.env

// app/api/data/route.ts with caching
import { getCloudflareContext } from '@opennextjs/cloudflare';

export async function GET() {
    // Read bindings inside the handler, not at module scope.
    const { env } = getCloudflareContext();
    const kv = env.CACHE_KV;
    const apiKey = process.env.MY_API_KEY;

    if (!apiKey) {
        return Response.json({ error: 'Server configuration error' }, { status: 500 });
    }

    const cached = await kv.get('api_response');
    if (cached) {
        return new Response(cached, {
            headers: { 'Content-Type': 'application/json', 'X-Cache': 'HIT' },
        });
    }

    try {
        const response = await fetch(`https://api.example.com/endpoint?key=${apiKey}`);

        if (!response.ok) {
            return Response.json(
                { error: 'External API request failed' },
                { status: response.status }
            );
        }

        const data = await response.json();
        await kv.put('api_response', JSON.stringify(data), { expirationTtl: 600 });

        return Response.json(data, { headers: { 'X-Cache': 'MISS' } });
    } catch (error) {
        console.error('Proxy error:', error);
        return Response.json({ error: 'Upstream request failed' }, { status: 502 });
    }
}

El establece un TTL de 10 minutos. Después de 600 segundos, la entrada en caché expira y la siguiente solicitud obtiene datos frescos de la API externa. Ajusta este valor según la frecuencia con la que cambien tus datos.expirationTtl: 600

Cuidado con el límite inferior al ajustarlo: Webflow Cloud documenta un TTL de caché mínimo de 60 segundos , por lo que rechaza valores inferiores en lugar de aplicarlos. Eso descarta el almacenamiento en caché de menos de un minuto que la gente busca primero, como un TTL de 30 segundos para un marcador deportivo en vivo.

KV Store también es eventualmente consistente, con escrituras que se propagan globalmente en aproximadamente 60 segundos, por lo que el límite efectivo de frescura es de aproximadamente un minuto en cualquier caso. Para cualquier cosa que deba ser idéntica en todas las regiones en el instante en que cambia, KV es la herramienta equivocada y querrás que la llamada se realice sin caché.

¿Qué causa que las integraciones de API externas fallen en Webflow?

La mayoría de los fallos de integración de API en Webflow Cloud se deben a cuatro problemas: un 404 en el endpoint del proxy, una clave de API faltante en producción, un error de CORS por una llamada del lado del cliente mal ubicada o datos obsoletos que no reflejan cambios recientes.

Cada uno tiene un síntoma distinto. Aquí te explicamos cómo identificarlos y solucionarlos.

404 en el endpoint del proxy después del despliegue

Síntoma: Tu ruta de API funciona en desarrollo local (npm run dev), pero devuelve un error 404 en mysite.webflow.io/app/api/data tras la implementación.

Causa 1: No has publicado el sitio de Webflow después de crear el entorno. Crear un entorno de Webflow Cloud no activa automáticamente la ruta de montaje. El error 404 aparece porque la capa de enrutamiento de Webflow aún no reconoce el nuevo entorno.

Solución: Si aún no has publicado el sitio de Webflow, hazlo ahora. Haz clic en "Publicar" en la esquina superior derecha del Diseñador o del Panel de control y espera entre 10 y 30 segundos. Para futuras implementaciones, ya no será necesario volver a publicar el sitio.

Causa 2: La aplicación de GitHub no tiene acceso al repositorio. Las implementaciones fallan silenciosamente cuando Webflow Cloud no puede leer el repositorio.

Solución: Ve a la configuración del sitio, abre la barra lateral de Webflow Cloud y haz clic en "Instalar GitHub". Sigue las instrucciones de GitHub para confirmar que Webflow Cloud tiene acceso de lectura a tu repositorio específico. Tras confirmar el acceso, envía un commit para activar una nueva compilación.

Causa 3: Ruta de montaje incorrecta en la URL de fetch. Tu entorno está configurado con la ruta de montaje /app, pero tu Code Embed realiza la petición desde /api/data, la cual no existe en la capa de enrutamiento de Webflow.

Solución: Añade siempre la ruta de montaje completa como prefijo a la ruta de fetch. Verifica la configuración de tu entorno en la barra lateral de Webflow Cloud para confirmar la ruta de montaje exacta y, a continuación, actualiza la llamada fetch() en tu Code Embed para que coincida.

Clave de API no encontrada en producción

Síntoma: El proxy devuelve un 500 Server configuration error en producción, pero funciona en desarrollo local donde .env está presente.

Causa: Las variables de entorno añadidas en Webflow Cloud solo están disponibles después de la siguiente implementación. Si configuraste la variable después de la última compilación, la aplicación que se está ejecutando actualmente aún no la reconoce.

Solución: Después de añadir cualquier variable de entorno en Webflow Cloud, activa una nueva implementación enviando un commit a GitHub o ejecutando webflow cloud deploy desde tu terminal. Revisa los registros de compilación en la sección de Implementaciones para confirmar que el proceso se completó.

Además, verifica que el nombre de la variable respete las mayúsculas y minúsculas. MY_API_KEY y my_api_key son variables distintas, y la discrepancia no genera un error, solo un undefined en tiempo de ejecución.

Errores de CORS en peticiones del lado del cliente

Síntoma: La consola del navegador muestra errores de Access-Control-Allow-Origin al llamar a una API externa desde un Code Embed.

Causa: Un navegador está realizando una solicitud de origen cruzado a una API que no devuelve una cabecera Access-Control-Allow-Origin que permita tu dominio, por lo que el navegador se niega a entregar la respuesta a tu JavaScript.

Ten en cuenta que esto no tiene nada que ver con las credenciales: una API totalmente pública y sin claves activará el mismo error si omite esas cabeceras, razón por la cual esto afecta al Método 2 con tanta frecuencia. Solo afecta a las solicitudes iniciadas por el navegador; las llamadas de servidor a servidor no están sujetas a CORS en absoluto.

Solución: Traslada la llamada a la API a una ruta proxy de Webflow Cloud. Tu Code Embed realiza la petición desde /app/api/data (mismo dominio, sin comprobación de CORS), y el proxy realiza la petición a la API externa desde el lado del servidor. El error de CORS desaparece porque la segunda solicitud es de servidor a servidor. Esto también resuelve el problema de exposición de claves.

Qué construir a continuación con tu integración de API en Webflow

Una vez que el proxy funciona, el mismo patrón cubre la mayoría de las integraciones de terceros en Webflow Cloud. Para ver un ejemplo práctico que añade una base de datos detrás del proxy, consulta nuestra guía de Neon Postgres; para uno que escribe de vuelta en el CMS, consulta la guía de la API de CMS.

Un proxy funcional del lado del servidor convierte a Webflow Cloud en una capa de backend full-stack. Una vez que el patrón está consolidado, la mayoría de los equipos lo extienden en dos direcciones: exponer el CMS de Webflow como una API consultable y construir flujos de datos más complejos.

Explora la documentación para desarrolladores de Webflow y descubre todo su potencial de extensibilidad: la API de datos para gestionar contenido, la API del Designer para realizar cambios de diseño mediante programación, los componentes de código para usar elementos de React reutilizables en el lienzo visual y las tres opciones de almacenamiento de Webflow Cloud (KV Store, SQLite y Object Storage) para mantener el estado del backend.