Cómo migrar de Firecrawl a Nstdata: una guía para desarrolladores
TL;DR
Un movimiento de Firecrawl a Nstdata es una migración de adaptador, no un simple intercambio de URL base.
Mapea las rutas de inicio, sondeo, colección, normalización y error por separado; mantén tu esquema de documento descendente estable.
Las secciones de inicio rápido y ruta públicas de Nstdata difieren en las rutas de raspado sincrónicas, así que confirma la referencia API en vivo de tu cuenta antes de conectar solicitudes de producción.
Una pequeña integración de camino feliz puede tardar 30 minutos; el tiempo total de migración depende de tus filtros de rastreo, manejo de errores y pruebas de aceptación.
¿Qué cambia cuando migras?
La guía de API Crawl de Firecrawl describe POST /v2/crawl, un ID de trabajo, sondeo a través de GET /v2/crawl/{jobId}, y un enlace paginado next para resultados completados. Nstdata Crawl documenta una ruta de envío de rastreo de sitio, búsqueda de estado, listado de páginas y lecturas de almacenamiento separadas para referencias de artefactos. Eso significa que el límite de la aplicación debería ser un adaptador interno crawl_site() que devuelva tus propios registros de páginas. Mantén la segmentación RAG y el almacenamiento vectorial ajenos a las formas de respuesta del proveedor.
Descubre Nstproxy Crawl - Empieza Tu Prueba Gratuita Hoy
Traducir opciones de URL, ruta y límite
Sondear trabajo
GET /v2/crawl/{jobId}
GET /api/v1/crawl/status/{crawlId}
Normalizar estado y errores terminales
Recoger páginas
Páginas de resultados de rastreo y next
GET /api/v1/crawl/pages/{crawlId}
Paginación hasta completar
Leer contenido
Contenido de página en línea
Referencia de artefacto como markdownRef
Resolver referencia de almacenamiento cuando sea necesario
Registrar fallos
Errores de rastreo más estado de página
Estados de trabajo y página
Retener campos de error originales del proveedor
La visión general de Scrapy es útil cuando posees el descubrimiento durante una transición. La documentación de API Crawl de Nstdata es la autoridad para los campos de solicitud y respuesta específicos de la cuenta. Sus secciones de inicio rápido y ruta muestran actualmente etiquetas inconsistentes de punto final de raspado. Este tutorial evita intencionalmente inventar un cuerpo de solicitud listo para producción o pretender que una sola ruta funcione para cada cuenta. Copia el ejemplo verificado de tu referencia en vivo, luego ejecuta la prueba de normalización a continuación.
Antes: mantén Firecrawl detrás de un adaptador
El siguiente ejemplo es ilustrativo y necesita tu clave de Firecrawl y SDK instalado. Muestra la unión a preservar, en lugar de una afirmación de que este entorno ejecutó un rastreo pago.
from firecrawl import Firecrawl
client = Firecrawl()result = client.crawl("https://example.com/docs", limit=50)
Evita que el código descendente acceda a campos específicos de Firecrawl en toda la aplicación. La llamada de conveniencia documentada .crawl() puede ocultar sondeo y paginación. Inspecciona su tipo de retorno de SDK actual antes de comprometer una implementación de reemplazo. Si tu pipeline utiliza extracción JSON, capturas de pantalla o filtros de rastreo, registra cada opción explícitamente. Esos tienen diferentes implicaciones de costo y esquema, descritas en el precio de créditos de Firecrawl.
Después: normaliza resultados antes de cambiar de proveedor
El siguiente código de Python es verificable sin conexión y utiliza solo la biblioteca estándar. Aliméntalo con diccionarios de página de un rastreo de Nstdata autenticado después de verificar la estructura de respuesta actual. Evita vincular el resto de tu pipeline RAG a un nombre de campo de proveedor.
from dataclasses import dataclass
from typing import Mapping, Any
@dataclass(frozen=True)classDocument: url:str markdown:str status:int|None source_id:str|Nonedefnormalize_nstdata_page(page: Mapping[str, Any], markdown:str)-> Document: url =str(page.get("url")or page.get("sourceUrl")or"")ifnot url.startswith(("http://","https://")):raise ValueError("Falta la URL de origen absoluta") body = markdown.strip()ifnot body:raise ValueError(f"Markdown vacío para {url}") raw_status = page.get("statusCode") status =int(raw_status)if raw_status isnotNoneelseNonereturn Document(url, body, status,str(page.get("id"))if page.get("id")elseNone)
Aquí markdown es el texto del artefacto recuperado; un token markdownRef no es el cuerpo en sí. La documentación de suscripción de Nstdata también hace que el tráfico proxy sea una consideración de costo separada. Mantén un libro mayor por página con la URL de entrada, URL canónica, estado, referencia de artefacto, tiempo de recuperación y unidades facturables.
Un esquema de script de migración que puedes adaptar
Utilice esta secuencia en un script de un solo uso: cargue un manifiesto de URL fijo; envíe una búsqueda de Nstdata limitada; sondee con retroceso hasta el terminal; enumere cada página de resultados; obtenga Markdown referenciado; llame a normalize_nstdata_page; compare las URL aceptadas con una línea base de Firecrawl; escriba un archivo de líneas JSON. Haga que el script sea reanudable desde crawlId, de modo que un tiempo de espera no inicie una búsqueda pagada duplicada. Limite la concurrencia y registre los ID de solicitud para diagnosticar fallas parciales. No descarte silenciosamente páginas 403, 404, vacías o duplicadas.
Una ejecución seca exitosa debería demostrar que el mismo fragmentador de downstream acepta ambos adaptadores. También debería encontrar URL eliminadas, canónicos duplicados, cambios en tablas o cercas de código, y diferencias en los encabezados. La guía de la base de conocimientos RAG, estrategias de fragmentación, y método de tasa de éxito de búsqueda proporcionan controles para esta entrega. La prueba debería comparar documentos aceptados y calidad de respuesta, no igualdad de Markdown byte por byte.
¿Qué suele tardar más de 30 minutos?
La configuración de autenticación, la verificación de rutas, la paginación de resultados, las lecturas de almacenamiento de artefactos, los filtros de ruta cambiados, la política de reintentos y el monitoreo tardan más que reemplazar una llamada SDK. Permita un concepto de prueba de 30 minutos para un sitio pequeño; presupuestar por separado para la paridad de producción. Mantenga la ruta de Firecrawl detrás de una bandera de característica hasta que el adaptador de Nstdata pase su corpus y umbrales de costo. El cambio está completo cuando funcionan las recapturas programadas, la eliminación y las alertas de errores, no cuando devuelve la primera página.
Experiencia Nstdata — Comience su prueba gratuita hoy
Realice una comparación limitada en un sitio que puede rastrear e inspeccione los artefactos de página reales antes de mover trabajos programados.
P: ¿Puedo reemplazar la URL base de Firecrawl con la de Nstdata?
No. El ciclo de vida del trabajo, las referencias de salida, la paginación y los campos de error necesitan un adaptador.
P: ¿La migración siempre tarda menos de 30 minutos?
No. Un prototipo pequeño y en el camino feliz puede, pero la migración en producción depende de las características y pruebas de aceptación que utilice.
P: ¿Por qué una referencia de Markdown no es suficiente?
Identifica la salida almacenada; obtenga el artefacto y valide su contenido antes de fragmentarlo.
P: ¿Deberíamos volver a rastrear todo el corpus de inmediato?
Comience con una muestra representativa limitada y un despliegue reversible. Compare páginas aceptadas, frescura y costos antes de escalar.
Lena Zhou
Oct. 16th 2026
Rastrea sitios web completos con una sola solicitud API
99,8% de éxito con renderizado JavaScript
Obtén datos limpios, listos para LLM, en múltiples formatos
Convierte cualquier sitio web en Markdown, HTML, JSON, enlaces, PDF y más, sin gestionar infraestructura de rastreo.
