source.unsplash.com ha desaparecido: la autopsia y todas las formas de sustituirlo

Un servicio de fotografía de stock desactivó un subdominio, y dos años después sigue rompiendo sitios de documentación, pantallas de inicio de sesión, ejercicios de cursos y código recién generado. Este es el examen post mortem de una URL — qué hacía, qué la mató y qué poner en su lugar — junto con una mirada mesurada a la parte más extraña de la historia: las máquinas que escriben nuestro código no se han enterado de que ha desaparecido.

Las respuestas HTTP, las dos entradas del changelog citadas palabra por palabra, los límites de la API, los rastreadores de incidencias de los proyectos que se rompieron y los recuentos de GitHub, npm y Stack Overflow proceden todos de fuentes primarias, con el método de cada uno en las notas al pie. Si solo quieres la solución, salta a la tabla de migración.

Qué obtienes hoy, si aún la solicitas

Un solo comando, sin clave, reproducible desde cualquier máquina:

curl -I https://source.unsplash.com/random

HTTP/2 503
cache-control: no-cache, no-store
content-type: text/html; charset=utf-8
server: Heroku
via: 2.0 heroku-router
# cuerpo: un iframe apuntando a herokucdn.com/error-pages/application-error.html

Nada de esto es un fallo de DNS. source.unsplash.com todavía resuelve — es un CNAME a un host de herokudns.com — así que la petición se responde, simplemente no por una aplicación. Ese detalle importa más de lo que parece: un navegador que recibe un 503 rápido con un cuerpo HTML renderiza un icono de imagen rota, y cualquier código que lea response.ok o un manejador onerror que nunca escribiste toma la ruta de fallo que nunca probaste.

Desliza la tabla lateralmente para ver todas las columnas →

Comprobado individualmente con curl -o /dev/null -w "%{http_code}". La función de búsqueda se desactivó primero, tal como se anunció; hoy toda la aplicación está apagada, así que la distinción ya no existe.

Tres años entre “obsoleto” y “apagado”

Ambos anuncios se pueden leer aún, en un solo lugar, en unsplash.com/documentation/changelog. Citados en su totalidad, porque la redacción es toda la historia:

25 de noviembre de 2021 — “Unsplash Source being deprecated”
“Unsplash Source is being deprecated. Existing uses will continue to work, however for new projects use the full Unsplash API.”

11 de junio de 2024 — “Unsplash Source sunset”
“Unsplash Source has been officially unsupported since its deprecation in 2021. As part of the final sunsetting, we will first wind down by disabling the search feature, and in the coming weeks turn off the application entirely. Existing uses of Source — particularly production-level ones — should migrate as soon as possible to the full Unsplash API.”

Leídos en secuencia, el modo de fallo es obvio. El aviso de 2021 contenía una promesa (los usos existentes seguirán funcionando) y ninguna fecha. Un desarrollador que lo leyó en 2021 tenía todas las razones para dejar el código en funcionamiento tal cual; un desarrollador que se incorporó en 2022 nunca lo leyó en absoluto. El aviso de 2024 dio “las próximas semanas”, tres años después, en una página que nadie había guardado en marcadores.

Unsplash sí publica una política de obsolescencia, y es razonable — la documentación indica que para los campos y endpoints documentados públicamente, los cambios se anuncian en el changelog con al menos 3 semanas de aviso, y los endpoints devuelven una cabecera Warning durante el periodo de obsolescencia. El mismo párrafo contiene la frase que explica por qué nada de eso protegió a Source: “For any non-publicly documented fields or endpoints, we may make changes to these with no warning.” Source nunca fue un endpoint de la API documentada. Quedaba fuera de la política que lo habría cubierto.

• La lección práctica no es “Unsplash fue descuidada”. Es que una URL que puedes usar sin leer ninguna documentación es una URL cuya política de obsolescencia tampoco has leído.
• La rotura precedió al anuncio. Una incidencia de Drupal registrada el 28 de noviembre de 2022 ya informa de “I get always a Heroku application error”, dieciocho meses antes de la entrada de retirada. Así mueren estos servicios: lentamente, y luego en un anuncio que nunca ves.

El anuncio es más difícil de encontrar que la propia caída

La obsolescencia de 2021 se publicó en changelog.unsplash.com, y esa es la URL a la que enlaza cada informe de error de la época — incluido el de Drupal citado arriba. Tres mediciones:

1. El endpoint HTTPS está roto. openssl s_client -connect changelog.unsplash.com:443 devuelve tlsv1 alert internal error — el handshake falla antes de que se presente ningún certificado. Por tanto, todo enlace de la era 2021, que era https://, está muerto en un navegador.
2. Por HTTP plano redirige, pero no de forma útil. Siguiendo http://changelog.unsplash.com/deprecations/2021/11/25/source-deprecation.html se termina, dos saltos después, en un 400 en unsplash.com/@documentation/changelog/deprecations/2021/11/25/source-deprecation/html — la ruta ha sido absorbida por la ruta de nombres de usuario del sitio.
3. El archivo tiene un hueco justo donde está la retirada. La última captura exitosa del changelog antiguo en la Wayback Machine es del 24 de marzo de 2024; su primera captura del nuevo es del 23 de agosto de 2024. La retirada se anunció el 11 de junio de 2024 — dentro de ese hueco de cinco meses.

Nada de esto es una conspiración; es una migración de CMS ordinaria. Pero la consecuencia es real, y es la razón por la que este artículo cita ambas entradas en su totalidad: el registro primario de una obsolescencia debería sobrevivir a aquello que declara obsoleto, y aquí casi no lo hizo.

Qué se rompió realmente

No proyectos secundarios. Los fallos siguientes son entradas públicas de rastreadores de incidencias; los títulos, fechas y estados proceden de las APIs de GitHub y drupal.org.

Desliza la tabla lateralmente para ver todas las columnas →

Vuelve a leer esa última fila, porque es la que merece la pena interiorizar. Una imagen decorativa junto a un formulario de inicio de sesión — el recurso más obviamente no crítico de la página — degeneró en una caída de autenticación, porque una petición lenta a un tercero se interponía delante del CAPTCHA que necesitaba el formulario de inicio de sesión. Nadie lo diseñó así. Surgió del orden en el que un navegador carga las cosas.

Tu asistente de código no recibió el memo

Aquí está la parte que convierte una caída de 2024 en un problema de 2026. source.unsplash.com estuvo documentado, publicado en blogs, enseñado y copiado durante unos ocho años. Todo ese texto está en los datos de entrenamiento de los modelos que ahora escriben nuestro código inicial — y el texto no caduca. Tres recuentos:

Desliza la tabla lateralmente para ver todas las columnas →

La evidencia más directa no está en absoluto en código de aplicación — está en los prompts. El primer resultado de esa búsqueda es una biblioteca de prompts de sistema de GPT que contiene la línea “please use unsplash API( https://source.unsplash.com/1280x720/?<PUT YOUR QUERY HERE>”. Esa instrucción se sigue copiando hoy en día en nuevos asistentes. El modelo no verifica la URL; se le indicó que la usara, y todos los ejemplos que ha visto coincidían.

Así que el fallo del código generado tiene dos causas independientes, y arreglar una no arregla la otra: datos de entrenamiento obsoletos, e instrucciones obsoletas escritas por humanos sobre ellos. En cualquier caso, el síntoma es la misma familia de imágenes que nunca cargan:

source.unsplash.com/random/1200x800   # 503 desde mediados de 2024 — nunca vuelve
images.unsplash.com/photo-…           # CDN real, pero los IDs memorizados pueden no existir
via.placeholder.com/400               # rectángulo gris, enviado a producción
placehold.co/800x600                  # rectángulo gris, a propósito
picsum.photos/800/600                 # una foto real, sin relación con tu página
/placeholder.png                      # un archivo que nunca se añadió al repositorio

Una nota al pie sobre la segunda línea de esa lista: mientras escribíamos esto, via.placeholder.com tampoco completaba el handshake TLS desde nuestra red de pruebas, y respondía 403 por HTTP plano. Compruébalo desde tu propia red antes de confiar en él — la alternativa a la que recurren estas herramientas puede tener su propia historia de caídas.

Solo el primero está roto. Los demás son peores de una forma más sutil: cargan, la maquetación parece terminada, y nadie nota que la página está ilustrada con nada en particular. Y nada de esto es específico de las imágenes — es la forma general del problema. La imagen que un modelo tiene de la web es una instantánea, y los endpoints, las opciones de CLI, los nombres de paquetes y los planes gratuitos siguen moviéndose después de que se cierra el obturador.

La tabla de migración

Hay exactamente tres destinos, y la forma honesta de presentarlos es por lo que renuncias. Elige primero la columna, luego lee tu fila.

Desliza la tabla lateralmente para ver todas las columnas →

La opción A es la que la mayoría de la gente realmente quiere. Si la imagen era decorativa — una cabecera, un panel lateral de inicio de sesión, un fondo de tarjeta — nunca necesitaste una foto distinta en cada petición. Elige una, conserva la URL de CDN, y la página deja de depender de nada aleatorio:

<img src="https://images.unsplash.com/photo-1506905925346-21bda4d32df4?w=1600&h=900&fit=crop&auto=format"
     width="1600" height="900" alt="…">
# Parámetros oficialmente soportados: w, h, crop, fit, fm, auto=format, q, dpr.
# Conserva cualquier parámetro ixid que te diera la API — es lo que reporta la vista.

La opción B es el camino oficial, y traslada la llamada al servidor, porque un Client-ID en JavaScript de front-end es una credencial publicada. Fíjate en las dos reglas que suelen sorprender: collections/topics no se pueden combinar con query en la misma petición, y count (máx. 30) cambia la forma de la respuesta a un array incluso cuando es 1.

curl "https://api.unsplash.com/photos/random?query=nature&orientation=landscape" \
  -H "Authorization: Client-ID YOUR_ACCESS_KEY" \
  -H "Accept-Version: v1"

# → JSON. La imagen está en .urls.regular / .urls.raw (añade w/h/fit tú mismo).
# → X-Ratelimit-Limit: 1000   X-Ratelimit-Remaining: 999

Opción C: reconstruir Source, en unas cuarenta líneas

Si lo que perdiste fue realmente el comportamiento — una URL sin clave que devuelve una foto distinta cada vez, utilizable directamente desde una etiqueta <img>, en un campo de CMS, o en un sitio estático donde no hay servidor — entonces tienes que ejecutar ese endpoint tú mismo. Es un pequeño worker delante de la API, y las tres cosas que hacen que sobreviva al contacto con producción son la caché, la comprobación del referente, y pasar el resto de la cadena de consulta a la CDN.

// Cloudflare Workers. En otros sitios (Deno Deploy, Val Town…) la forma es la misma,
// pero abre una caché con nombre con caches.open() en lugar de caches.default.
// UNSPLASH_KEY se queda en el servidor. Los que llaman nunca la ven.
const ALLOWED = ["example.com", "www.example.com"];   // solo tus dominios
const API_PARAMS = ["query", "collections", "topics", "username", "orientation"];
const TTL = 60;                                       // segundos — protege la cuota horaria

const host = (value) => { try { return new URL(value).hostname; } catch { return null; } };

export default {
  async fetch(req, env, ctx) {
    // 0. Solo GET: la Cache API se niega a almacenar cualquier otra cosa, y un endpoint
    //    de imágenes no tiene otro verbo al que responder.
    if (req.method !== "GET")
      return new Response("Method not allowed", { status: 405 });
    const url = new URL(req.url);

    // 1. Solo tus propias páginas pueden incrustarlo — un endpoint público de foto
    //    aleatoria en la internet abierta es el límite de tasa de otro para gastar.
    const ref = req.headers.get("referer");       // ausente en muchos clientes legítimos
    if (ref && !ALLOWED.includes(host(ref)))
      return new Response("Forbidden", { status: 403 });

    // 2. Cachea por combinación de parámetros, para que una página con 12 imágenes
    //    cueste una llamada a la API por minuto en lugar de doce por render.
    const cache = caches.default;
    const hit = await cache.match(req);
    if (hit) return hit;

    // 3. Pide a la API oficial una foto aleatoria.
    const api = new URL("https://api.unsplash.com/photos/random");
    for (const p of API_PARAMS)
      if (url.searchParams.has(p)) api.searchParams.set(p, url.searchParams.get(p));

    const r = await fetch(api, { headers: {
      Authorization: "Client-ID " + env.UNSPLASH_KEY,
      "Accept-Version": "v1",
    }});
    // Un 403 aquí suele significar la cuota horaria, no una clave incorrecta — sube el TTL, no cunda el pánico.
    if (!r.ok) return new Response("Upstream " + r.status, { status: 502 });
    const photo = await r.json();

    // 4. Reconstruye la URL de la imagen: conserva ixid, añade los parámetros de tamaño del cliente.
    const img = new URL(photo.urls.raw);          // .raw ya lleva ixid
    for (const [k, v] of url.searchParams)
      if (!API_PARAMS.includes(k)) img.searchParams.set(k, v);  // w, h, fit, q…

    const res = new Response(null, { status: 302, headers: {
      Location: img.toString(),
      "Cache-Control": "public, max-age=" + TTL,
      // El crédito viaja con la redirección; los valores de cabecera deben ser ASCII, de ahí la codificación.
      "X-Photo-Credit": encodeURIComponent(photo.user.name + " on Unsplash"),
      "X-Photo-Link": photo.links.html,
    }});
    ctx.waitUntil(cache.put(req, res.clone()));
    return res;
  },
};

Migrar una URL es entonces un buscar-y-reemplazar, que es exactamente lo que hace que esta opción merezca los veinte minutos:

- https://source.unsplash.com/collection/67920491/1600x900
+ https://img.example.com/?collections=67920491&w=1600&h=900&fit=crop

Dos notas de diseño, ambas resultado de una mala tarde que alguien pasó antes de anotarlas. La redirección (302) en lugar de reenviar los bytes te evita responsabilizarte del ancho de banda y mantiene contabilizada la vista en la CDN de Unsplash, que es lo que piden las directrices. Y la comprobación de Referer es deliberadamente permisiva cuando la cabecera está ausente — muchos clientes legítimos la eliminan — mientras sigue deteniendo el caso obvio de que tu endpoint se convierta en la API gratuita de imágenes de otra persona.

Las reglas que heredas en el momento en que usas la API

Source no tenía reglas porque no tenía cuenta. La API tiene cinco que cambian cómo diseñas el sistema, todas de la documentación actual:

• Los límites de tasa son por hora, y pequeños al principio. 50 peticiones/hora en modo demo; 1.000/hora una vez que tu aplicación es aprobada para producción. Solo cuentan las llamadas a api.unsplash.com — las peticiones de imágenes a images.unsplash.com no cuentan. Lee X-Ratelimit-Remaining en cada respuesta.
• El hotlinking es obligatorio, no meramente permitido. Unsplash exige que las URLs de imagen que devuelve la API se incrusten directamente, para que las vistas de fotos se puedan atribuir al fotógrafo. Reflejar el archivo en tu propia CDN es la única optimización que no eres libre de hacer.
• Conserva el parámetro ixid. Redimensionar y recortar la URL devuelta se espera; eliminar el parámetro que identifica tu aplicación no.
• La atribución y el seguimiento de descargas son parte del trato — se acredita al fotógrafo y a Unsplash, y una “descarga” se reporta a través del endpoint de descarga de la foto cuando un usuario toma el archivo, algo que tienes que disparar tú mismo.
• Los productos distribuidos necesitan registro dinámico de clientes. Si publicas un plugin, un tema o un CMS autoalojado, una única clave compartida es a la vez una infracción de la política y un punto único de fallo; la API tiene un flujo de registro exactamente para ese caso.

Este es el momento de ser honestos sobre el alcance: si de todos modos vas a conectar una API y una clave, la elección de qué API de imágenes usar queda de repente abierta, y merece la pena dedicarle cinco minutos antes de escribir el cliente. Comparamos las gratuitas — cuotas, reglas, comportamiento de búsqueda y formas de respuesta — en la comparación de APIs de fotos de stock gratuitas.

Si solo querías un marcador de posición, dilo

Una gran parte del uso de Source nunca tuvo que ver con Unsplash. Era “pon aquí algo con forma de imagen mientras construyo la maquetación”. Para eso, siguen existiendo servicios sin clave, y son la respuesta correcta:

Desliza la tabla lateralmente para ver todas las columnas →

La distinción que importa: un marcador de posición es temporal por definición. Si la imagen sobrevive hasta producción, ya no es un marcador de posición — es una ilustración que nadie eligió, y el lector se da cuenta.

Una clave en lugar de tres

Aquí está la parte de la migración que nadie planifica: quienes abandonan Source raramente aterrizan en una sola API. Una página necesita una cabecera, dos imágenes de sección y algo para una cuadrícula de tarjetas, y la respuesta honesta suele ser Unsplash más Pexels más Pixabay — tres registros, tres esquemas de autenticación, tres formas de JSON, tres modelos de paginación y tres conjuntos de reglas de atribución, todo para rellenar las mismas etiquetas <img>. Ese trabajo de integración es la factura real de que desaparezca una URL sin clave, y llega semanas después de la caída que lo causó.

Consolidar eso en una sola integración es para lo que construimos Pexafy: una única clave sobre 9 bibliotecas de licencia gratuita en un solo esquema, con búsqueda semántica a nivel de frase — de modo que una descripción completa como “a cracked phone screen on a wooden desk, shot from above” devuelve resultados clasificados en lugar de nada. Dos límites, expuestos con claridad, porque este artículo entero trata de no llevarse sorpresas dos veces: necesita una clave, así que no restaura lo que era Source — pertenece a la misma categoría que la API oficial de Unsplash de arriba; y contiene fotografía de licencia gratuita, no imágenes editoriales o de marca.

La parte que es genuinamente nueva está dirigida a los asistentes de arriba: un servidor MCP en mcp.pexafy.com/mcp significa que un modelo que de otro modo recitaría de memoria una URL de imagen puede buscar en un catálogo real y devolver una foto que existe, con su línea de crédito adjunta. Es una respuesta mejor a las URLs muertas escritas por máquinas que cualquier regla de lint, y el razonamiento está desarrollado en infraestructura de búsqueda de imágenes para agentes de IA.

Audita tu inventario en diez minutos

A lo que sea que migres, haz primero esta parte — no puedes arreglar URLs que no has encontrado. Source es solo el ejemplo de hoy; los mismos tres pasos se aplican a cualquier recurso externo que incrustes.

# 1. Todo en el repositorio, incluyendo documentación, tests, fixtures y READMEs.
grep -rn --binary-files=without-match \
  -e "source.unsplash.com" -e "via.placeholder.com" -e "/placeholder.png" .

# 2. Todo lo que guarda la base de datos — los cuerpos de CMS es donde esto se esconde más tiempo.
psql -c "SELECT id FROM posts WHERE body LIKE '%source.unsplash.com%'"

# 3. Todo lo que realmente solicita el sitio compilado: rastréalo y lista los fallos.
#    Coincide con el atributo, no con una extensión de archivo — las URLs de imagen rara vez terminan en .jpg.
grep -rhoE 'src="[^"]+"' dist/ \
  | cut -d'"' -f2 | grep -E '^https?://' | sort -u \
  | xargs -P8 -I{} curl -s -o /dev/null -w "%{http_code} {}\n" {} \
  | grep -v "^200"

# 503 https://source.unsplash.com/random/1200x800   ← lo que estás buscando

Después decide, de una vez, cuánto se les permite costarte a las imágenes externas. Cuatro reglas que sobreviven al próximo apagón, sea quien sea quien lo cause:

1. Obtén la imagen en el momento del build, no en el de la petición. Una imagen resuelta durante el build falla en CI, delante de un desarrollador, en lugar de a las 3 de la madrugada delante de un usuario.
2. Nunca dejes que un recurso decorativo bloquee una ruta crítica. No precargues nada externo por encima de un formulario de inicio de sesión; da a cada <img> de terceros un respaldo onerror y un width/height explícitos para que un fallo cueste una caja en blanco, no un salto de maquetación o un script bloqueado.
3. Añade la comprobación a CI. El paso 3 de arriba, ejecutado sobre tu salida compilada, convierte “alguien lo notó eventualmente” en un build en rojo. Es el único paso que evita que se repita.
4. Presupuesta tus dependencias externas como cualquier otra. Anota de qué hosts pueden depender tus páginas y qué pasa cuando cada uno cae. Una URL para la que no tuviste que registrarte sigue siendo una dependencia — Source demostró que simplemente es una que nadie posee.

Referencias y notas al pie