Captura móvil
Una página que se ve perfecta en una laptop puede esconder un menú de navegación roto en un teléfono real. Este endpoint renderiza una URL a través de viewports de dispositivos reales (teléfonos y tablets específicos) para que lo que ve sea realmente lo que ve un visitante móvil, no una ventana de navegador redimensionada fingiendo serlo.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
Pruebas con forma de escritorio en una web mobile-first
La mayor parte del tráfico de la mayoría de los sitios es móvil, y sin embargo buena parte del control de calidad visual todavía se hace achicando una ventana de navegador de escritorio, lo cual aproxima el diseño pero pasa por alto los detalles que realmente rompen la experiencia móvil: cómo se comporta un pie de página fijo en el área segura de un iPhone, cómo se recorta una imagen responsiva en un viewport Android más angosto, si un modal cubre la barra de direcciones de forma que atrapa al usuario. Probar sobre las formas reales de dispositivo detecta lo que una ventana redimensionada esconde en silencio.
Cómo funciona el renderizado
Se envía POST /web/screenshot-device con una URL y un perfil de dispositivo de destino, y la tarea renderiza la página usando las dimensiones de viewport reales de ese dispositivo, su densidad de píxeles y el comportamiento de su user-agent (iPhone, un teléfono Android o una tablet), de modo que tipografías, breakpoints y tamaño de zonas táctiles se renderizan como lo harían en el hardware físico. Como toda tarea del catálogo, funciona de manera asíncrona: devuelve un task_id de inmediato y entrega la imagen por webhook firmado o mediante un enlace firmado válido por 24 horas.
Por qué la precisión por dispositivo importa cada vez más
El diseño responsivo pretendía resolver esto con layouts fluidos, pero los breakpoints siguen siendo suposiciones de un desarrollador sobre dónde debería reacomodarse el contenido, y esas suposiciones suelen fallar para la larga cola de tamaños de pantalla realmente en uso: un teléfono plegable, un Android antiguo con otra relación de aspecto, un iPad en pantalla dividida. Renderizar contra perfiles de dispositivo reales en lugar de un puñado de breakpoints comunes es lo que convierte un 'debería funcionar' en un 'funciona'.
Uso común dentro de un equipo
Equipos de QA móvil que verifican un flujo de compra en distintos modelos de teléfono antes de un lanzamiento, equipos de marketing que confirman que una landing page se ve bien en los dispositivos que generan el tráfico de campaña, equipos de diseño que revisan cómo se sostiene un rediseño en una tablet además de en un teléfono, y equipos de soporte que reproducen un error reportado desde un dispositivo específico.
Automatizar las verificaciones por dispositivo
Con una base de $0.040 por solicitud más $0.001 por URL, correr la misma página a través de varios perfiles de dispositivo en cada despliegue sigue siendo asequible para programarlo con regularidad. Las capturas fallidas nunca se cobran, la tarea reintenta hasta tres veces antes de devolver un error claro, así que es seguro conectarlo a un pipeline que capture una URL de staging a través de una matriz de dispositivos sin revisar manualmente cada corrida.
Qué puede hacer con ella
QA móvil previo al lanzamiento
Un equipo captura el flujo de compra en perfiles de iPhone y Android antes de publicar, para detectar fallas de diseño que una vista previa de escritorio no mostraría.
Verificación de landing pages de anuncios
Un equipo de performance marketing confirma que una landing page se ve bien en los tipos de dispositivo que generan más clics de campaña.
Revisión de diseño en tablets
Un equipo de diseño revisa cómo se sostiene un nuevo layout en un viewport de tablet además de en tamaños de teléfono antes de aprobarlo.
Reproducción de errores
Un equipo de soporte captura una página exactamente como la renderizaría el dispositivo que reportó un cliente, para confirmar o descartar un error específico de ese dispositivo.
Preguntas frecuentes
¿Qué dispositivos puede renderizar la API de captura móvil?
Perfiles de dispositivo comunes que incluyen iPhone, teléfonos Android y tablets, cada uno con las dimensiones de viewport y densidad de píxeles reales de ese dispositivo.
¿En qué se diferencia de simplemente redimensionar una ventana de navegador?
Renderiza contra el viewport, la densidad de píxeles y el comportamiento de user-agent reales del dispositivo de destino, en lugar de aproximarlo achicando un navegador de escritorio.
¿Hay una prueba gratuita?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. El acceso funciona con un saldo prepago de ForHosting KIT: se recarga desde $10.00 (no caduca) y cada solicitud se cobra a su precio publicado, así que una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Cuál es el precio?
Una base de $0.040 por solicitud más $0.001 por URL, publicado por adelantado y sin recargo oculto por dispositivo.
¿Puedo capturar la misma página en varios dispositivos a la vez?
Sí, se envía una solicitud asíncrona por cada perfil de dispositivo; cada una se cobra y procesa por separado, lo cual se adapta bien a una matriz completa de dispositivos por lanzamiento.
¿Cómo recibo la captura?
Mediante webhook firmado cuando la tarea termina, o un enlace firmado válido por 24 horas.
¿Maneja correctamente los breakpoints responsivos?
Sí, porque renderiza a través del viewport real del dispositivo, el contenido se reacomoda exactamente como lo haría en ese dispositivo físico y no en un breakpoint aproximado.
¿Qué pasa si una captura falla?
Reintenta automáticamente hasta tres veces y nunca se cobra si falla; se devuelve un error claro una vez agotados los reintentos.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/web/screenshot-device \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://ejemplo.com"}'const res = await fetch("https://api.kit.forhosting.com/web/screenshot-device", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://ejemplo.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/screenshot-device",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://ejemplo.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/screenshot-device", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://ejemplo.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://ejemplo.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/screenshot-device", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"url": "https://ejemplo.com"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.screenshot_device",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
timeout_sec | 30 |
max_crawl_pages | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |