Planifica el día en que el enlace deje de funcionar
Un enlace temporal es práctico porque se limpia solo, pero todo lo que siga apuntando a él dejará de funcionar al terminar el periodo. Decide dónde se usará el enlace antes de elegir la duración.
- Guarda el archivo original en tu dispositivo. La copia alojada no es una copia de seguridad y no se puede recuperar tras la limpieza.
- Evita los enlaces temporales en sitios que se leerán más adelante, como README, wikis, artículos publicados o fichas de producto. Encajan en conversaciones y revisiones con final.
- Si una conversación se alarga, vuelve a subir la imagen antes de que caduque el enlace anterior y publica la nueva URL. La página de subida no permite ampliar una subida existente.
- Elige la duración más corta que cubra la tarea. Un enlace de 1 día para una respuesta rápida de soporte deja menos contenido en línea que uno de 30 días olvidado.
Cuándo empieza el reloj
Elige 1, 7 o 30 días en /upload antes de subir. El periodo debería empezar cuando la subida termina con éxito y se crea la URL.
Qué significa la caducidad en la práctica
- Tras el periodo elegido, el archivo alojado debería dejar de estar disponible en la URL original.
- La caducidad no promete que todas las cachés de navegador, CDN o terceros desaparezcan al instante.
- Si la página de subida muestra una hora de caducidad, trátala como el tiempo del servicio para esa subida.
Cómo se programa la retención temporal
El servicio de subida registra una hora de caducidad para las imágenes temporales. Las tareas programadas eliminan archivos caducados; el momento en que deja de funcionar un enlace público puede variar.
- El reloj de retención empieza cuando una subida temporal termina con éxito y se crea una URL alojada.
- Las respuestas de éxito de la API pueden incluir expires_at como marca de tiempo ISO-8601 UTC terminada en Z (estilo de ejemplo: 2026-08-05T12:00:00.000Z).
- expires_at se calcula desde el fin de la subida más 1, 7 o 30 días para duraciones temporales. El almacenamiento permanente no usa este campo de caducidad temporal.
- La página pública /upload muestra la retención elegida; puede que no muestre siempre el campo expires_at en bruto en el panel de resultado.
- El enlace original puede seguir accesible después de la hora de caducidad registrada hasta que se ejecute la limpieza. Las cachés del navegador, CDN o terceros pueden conservar copias más tiempo.
- Las tareas programadas eliminan objetos caducados después de la hora registrada; la marca de tiempo no garantiza una eliminación inmediata.
- Las subidas temporales ordinarias no son lo mismo que el almacenamiento permanente aprobado, que requiere un código de almacenamiento aprobado aparte en /upload.
- Para pedir la retirada de una imagen bajo tu control, envía la URL completa por la página de contacto o [email protected].
Caducidad frente a petición de retirada
La página pública no ofrece borrado instantáneo de autoservicio para subidas temporales normales. Para retirar una imagen bajo tu control, envía la URL por contacto o [email protected].
Esperar la caducidad y pedir la retirada son acciones distintas. El soporte gestiona la petición; no prueba que todas las cachés mundiales hayan desaparecido.
Qué duración elegir
1 díaVistas rápidas y chats de soporte cortos.
7 díasComentarios de borrador y revisiones breves.
30 díasReferencias temporales más largas que aún no deben ser permanentes.
FAQ
¿Cuándo empieza la cuenta atrás?
Tras una subida correcta que crea la URL con la duración elegida antes.
¿La caducidad limpia todas las cachés de inmediato?
No. El archivo debería dejar de estar en la URL; las cachés pueden retrasarse.
¿Puedo borrarla yo en la página?
No hay control público de borrado instantáneo para subidas temporales normales. Pide la retirada con la URL.
¿Qué incluir en la petición?
La URL completa y contexto suficiente de control o denuncia.
¿El almacenamiento permanente es lo mismo?
No. Requiere un código de largo plazo aprobado y otras reglas.