Captura móvil
Una página que se ve perfecta en una laptop puede esconder un menú de navegación roto al ancho de un teléfono.
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.
Este endpoint renderiza una URL con el ancho de pantalla de un móvil, una tablet o un escritorio —el tamaño de viewport y la densidad de píxeles que activan el diseño móvil, no un modelo con nombre— para que el diseño que ve sea realmente el que ve un visitante móvil, no una ventana de navegador redimensionada fingiendo serlo.
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 al ancho de un móvil, cómo se recorta una imagen responsiva en un viewport móvil más angosto, si un modal cubre el contenido de forma que atrapa al usuario. Probar con los anchos de pantalla reales 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 tamaño de pantalla de destino (móvil, tablet o escritorio, o un ancho a medida), y la tarea renderiza la página con las dimensiones de ese viewport y su densidad de píxeles, de modo que tipografías, breakpoints y tamaño de zonas táctiles se renderizan como lo harían a ese ancho de pantalla. 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 ancho de pantalla 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 móvil antiguo con otra relación de aspecto, una tablet en pantalla dividida. Renderizar a un ancho de destino real —uno de los tres preajustes o un ancho a medida que usted indique— en lugar de achicar a ojo una ventana de escritorio 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 a distintos anchos de teléfono antes de un lanzamiento, equipos de marketing que confirman que una landing page se ve bien a los anchos de pantalla 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 de diseño reportado a un tamaño de pantalla 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 tamaños de pantalla 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 tamaños de pantalla sin revisar manualmente cada corrida.
Qué puede hacer con ella
QA móvil previo al lanzamiento
Un equipo captura el flujo de compra a anchos de móvil y tablet 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 a los anchos de pantalla 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 se renderiza al ancho de pantalla que reportó un cliente, para confirmar o descartar un error de diseño propio de ese tamaño.
Preguntas frecuentes
¿Qué tamaños de pantalla puede renderizar la API?
Tres preajustes —un ancho de móvil, uno de tablet y uno de escritorio, cada uno con sus dimensiones de viewport y densidad de píxeles— más cualquier ancho a medida que usted indique.
¿En qué se diferencia de simplemente redimensionar una ventana de navegador?
Renderiza con las dimensiones de viewport y la densidad de píxeles reales del ancho de destino —y con la marca de viewport móvil activada, así las páginas responsivas sirven su diseño móvil— 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 tamaño.
¿Puedo capturar la misma página en varios tamaños a la vez?
Sí, se envía una solicitud asíncrona por cada tamaño de pantalla; cada una se cobra y procesa por separado, lo cual se adapta bien a una matriz completa de tamaños 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í; como renderiza al ancho de viewport real de destino, el contenido se reacomoda exactamente como lo haría a ese ancho en un navegador real 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, por email y desde Telegram — y pronto también desde nuestra app.
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://example.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://example.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://example.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://example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.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://example.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. |