Perfil

Ningún permiso aquí alcanza el de otra persona. Enviar solo los campos que cambian deja el resto como está.

{
  "data": {
    "draft": { "schema": 2, "page": { ... }, "sections": [ ... ] },
    "published": null,
    "version": 3,
    "published_version": null,
    "published_at": null,
    "updated_at": "2026-10-09T18:20:00.000Z",
    "customized": true,
    "draft_incomplete": false,
    "media": {
      "k3Jd8Qp2Lm": {
        "url": "https://media.uloggd.com/layout/.../....avif",
        "width": 1600, "height": 900, "animated": false
      }
    }
  }
}

{ "data": { "version": 4, "updated_at": "2026-10-09T18:21:02.000Z" } }

{ "data": { "reset": true } }

{ "data": { "version": 4, "published_at": "2026-10-09T18:22:10.000Z" } }

{
  "data": [
    {
      "id": "k3Jd8Qp2Lm", "url": "https://media.uloggd.com/layout/.../....avif",
      "width": 1600, "height": 900, "bytes": 184320, "animated": false,
      "created_at": "2026-10-11T19:02:00.000Z", "in_use": true
    }
  ],
  "quota": { "limit": 15, "count": 1, "bytes_limit": 10485760, "bytes": 184320 }
}

{
  "data": {
    "id": "k3Jd8Qp2Lm", "url": "https://media.uloggd.com/layout/.../....avif",
    "width": 1600, "height": 900, "bytes": 184320, "animated": false,
    "created_at": "2026-10-11T19:02:00.000Z"
  }
}

{ "data": { "id": "k3Jd8Qp2Lm", "deleted": true } }

El layout de Profile Studio

Un perfil se puede componer con bloques organizados en secciones y columnas, y con áreas libres donde imágenes, textos y formas quedan donde el dueño los pone. La composición es un documento JSON por perfil, guardado en dos copias: el borrador (draft), que solo lee el dueño y que cada PUT reemplaza, y la copia publicada (published), que es lo que ven los visitantes. Guardar nunca cambia lo que ven los visitantes; POST /api/v1/profile/layout/publish copia el borrador guardado sobre el publicado. Sin nada guardado, el borrador es el layout por defecto, el perfil que todos ya conocen, y published es null (los visitantes ven el de por defecto). DELETE vuelve a él para todos. Cuando el borrador guardado tiene algo que esta versión del sitio no sabe leer (un tipo de bloque de una versión más nueva), draft_incomplete es true y draft llega sin esa parte: guardar encima la borra.

El type de cada bloque es uno de un conjunto cerrado, y cualquier otro se rechaza: identity, shortcuts, social, stats, showcase, games, reviews, activity, lists, screenshots, image, comments, text, heading, divider, spacer. El config de un bloque guarda opciones y referencias (el slug de un juego, el id público de una captura), nunca marcado, script ni URL. identity, el encabezado del perfil, es obligatorio y no se puede ocultar.

El documento

El documento actual es el schema 2. page guarda el ancho (width), el espacio entre las secciones (density) y un fondo opcional (background), y sections tiene de 1 a 12 secciones, cada una de un kind:

• flow: de 1 a 3 columns en una cuadrícula de 12 (los span suman 12), cada columna con hasta 12 bloques, uno debajo del otro.
• canvas: un área de proporción fija, con aspect (la altura sobre el ancho, de 0.2 a 3) y phone (scale encoge el área entera en el móvil, stack apila los elementos en una columna en el orden en que se ven: de arriba abajo y, en una misma fila, de izquierda a derecha). Guarda hasta 24 elements en posición libre: box da x, y, w y h en fracciones del ancho del área, con w y h desde 0.001, y ningún elemento se sale del borde (el editor mantiene lo que no es una línea en 0.02 o más). Cada elemento tiene rotation, opacity, locked, visibility y un type: image, text, shape o block, que incrusta un bloque stats, social, heading, shortcuts o image. El orden de la lista es el orden del dibujo (el último queda encima) y también el orden en que lo lee un lector de pantalla.

Los textos y los bloques incrustados se componen en un ancho de referencia de 1000px y después se escalan junto con el área, como una imagen: un text de size 0.05 mide 50px en ese ancho, y una caja de w 0.4 mide 400px. Así cortan las líneas en los mismos lugares en cualquier ancho. Con phone scale, un texto se encoge con el área en el móvil, sin tamaño mínimo; con stack, vuelve a ser texto al ancho de la columna, con el 60% del tamaño que tiene en el ancho de referencia, entre 12px y 40px. El editor mantiene la altura de la caja de un texto, de un bloque incrustado y de una línea ajustada a lo que contiene.

Una shape line es un trazo en el medio de su caja, con un thickness opcional (de 0.001 a 0.05 del ancho del área), que se escala con el área y nunca queda por debajo de 1px. Una línea guardada antes de que existiera thickness sigue usando strokeWidth, contado en píxeles en un ancho de 1000px. En un rectángulo o un círculo, strokeWidth es el borde, en píxeles.

La página, una sección y el style de un bloque pueden tener background, que es siempre una imagen: media (la imagen, o null, que no dibuja nada), fit, position, dim (de 0 a 80, cuánto se oscurece la imagen para que el texto siga legible) y tone (auto, light o dark: el tema que siguen los colores del propio sitio encima de la imagen, para que el texto siga legible en cualquier tema). light y dark fijan ese tema; auto usa dark cuando el dim es 50 o más y, por debajo de eso, deja el tema del visitante. Sin imagen dibujada, tone no cambia nada. No existe color de fondo ni color de texto: el texto, incluido el de un elemento text, sigue siempre el tema, y solo una shape tiene colores propios (fill y stroke, #rrggbb o null). Una imagen nunca es una URL, sino una referencia: { "kind": "media", "id": "..." } para una imagen subida en Imágenes del layout, { "kind": "screenshot", "id": "..." } para una captura del dueño y { "kind": "cover", "slug": "..." } para la portada de un juego. Una referencia a la imagen de otra persona, o a una que ya no existe, no dibuja nada.

El perfil entero tiene como máximo 40 bloques (los de las columnas y los incrustados en las áreas libres, sumados) y 80 elementos. Un documento schema 1, de antes de las áreas libres y los fondos, se sigue aceptando en un PUT: se convierte al 2 (cada sección pasa a flow, sin fondo, y el screenshot del bloque image pasa a source) y se guarda ya así, por lo que el siguiente GET responde schema 2.

Un PUT que todavía envía los colores de antes no se rechaza: se descartan, en cualquier schema. Son color en un background (un background que tenía color y ninguna media pasa a null), textColor en el style de un bloque y color, background y radius en el config de un elemento text. Un documento guardado con ellos se lee sin ellos, así que ningún GET los trae.

Versiones

version cuenta los cambios del borrador. GET responde la actual (0 cuando no hay nada guardado), y cada guardado y publicación cita la versión en la que se basó. Si el borrador cambió entretanto, en otra pestaña u otro dispositivo, la respuesta es un conflicto que trae la versión actual, para que el editor ofrezca recargar en lugar de sobrescribir el trabajo de alguien:

{
  "error": {
    "code": "conflict",
    "message": "The layout changed elsewhere. Reload it before saving.",
    "version": 5
  }
}

Guardar un borrador idéntico al guardado mantiene la misma versión. Después de un DELETE, el próximo guardado cita la versión 0 otra vez.

Validación

El documento se revisa entero antes de guardarse: la forma, ids únicos, columnas cuyos spans suman 12, los límites de bloques por tipo y en total, los de elementos, elementos dentro de su área, el encabezado obligatorio y como máximo 48000 bytes. Un rechazo lista lo que está mal, hasta 20 problemas, cada uno con un code estable (shape, duplicate_id, spans, too_many_blocks, too_many_of_type, too_many_elements, out_of_bounds, required_missing, required_hidden, too_large), un message para personas y, cuando corresponde, el path dentro del documento y el type del bloque:

{
  "error": {
    "code": "invalid_request",
    "message": "The layout is not valid.",
    "issues": [
      {
        "code": "spans",
        "message": "The columns of a section must add up to 12.",
        "path": ["sections", 1, "columns"]
      }
    ]
  }
}

Imágenes del layout

Un layout puede mostrar imágenes que el dueño subió para él, y el documento las cita por id, nunca por URL. POST /api/v1/profile/layout/media recibe el archivo como multipart/form-data en el campo image (JPEG, PNG, WebP, GIF o AVIF, hasta 15 MB), lo reduce para caber en 1600x1600 y lo optimiza: una imagen fija pasa a un AVIF de unos 300 KB, nunca más de 1 MB, y una animación (GIF o WebP) a un WebP de hasta 3 MB y 10 segundos. Después lo pasa por la misma verificación de contenido que un avatar (una imagen sensible se rechaza, porque una página de perfil no tiene cómo cubrirla), lo guarda en el alojamiento de imágenes y responde con el id, la url, width, height, bytes y animated.

Una imagen rechazada es 400 invalid_request con un reason: invalid_format, too_large, invalid_image, too_many_frames, too_many_pixels, animation_too_long, unsupported_animation, too_heavy o sensitive_image (la tabla de arriba dice qué significa cada uno). too_heavy es una imagen que sigue siendo demasiado pesada incluso después de optimizarla, casi siempre una animación larga o grande:

{
  "error": {
    "code": "invalid_request",
    "message": "That image is still too heavy after optimization. Use a shorter or smaller animation.",
    "reason": "too_heavy"
  }
}

Una cuenta guarda hasta 15 imágenes y 10 MB (10485760 bytes); pasado eso la respuesta es 409 con reason: "quota_exceeded", limit, count, bytes_limit y bytes. Una cuenta que ya tenía más cuando el límite bajó conserva todo lo que tiene, pero solo vuelve a subir después de borrar lo suficiente para quedar por debajo.

GET /api/v1/profile/layout/media lista las imágenes con in_use, que dice si el borrador o el publicado cita el id, y la quota junto a data. DELETE /api/v1/profile/layout/media/{id} borra una; mientras un layout todavía la cita, la respuesta es 409 con reason: "in_use", y ?force=true la borra igual. Una imagen que ningún layout cita desde hace siete días se elimina sola.

Estos tres endpoints son solo de la sesión del sitio: una clave recibe 403, como en Cuenta, y la subida y el borrado responden 403 con reason: "mfa_required" mientras la sesión aún debe el segundo factor. En las lecturas, media resuelve cada id en url, width, height y animated: en GET /api/v1/profile/layout, todas las imágenes del dueño; en GET /api/v1/profiles/{username}/layout, solo las que cita el documento publicado, para que una imagen subida para el borrador no aparezca antes de publicarse.

Los visitantes leen el layout publicado con GET /api/v1/profiles/{username}/layout, en Personas.