API REST

Cuenta, personas y marca

La persona del token, los perfiles, las fotos, los logos y la eliminación de la cuenta.

  • GET /me (tracker:read): la persona (user, con id, name, email, locale y avatar_url), la organización, los proyectos con el perfil en cada uno, el token y la versión de tracker (server). Cada empresa de organizations trae slug, public_url (la dirección pública de la empresa, como https://suaempresa.centraldeajuda.ia.br: la raíz es el centro de ayuda, /status la página de estado publicada y /suporte/... e /ideias/... el portal de la mesa de ayuda y los tableros de ideas; null con la dirección pública desactivada), app_url (la empresa en tracker, null sin subdominio por empresa) y brand con square_logo_url y wide_logo_url (públicos, null sin el logo). whoami trae public_url también.
  • Idioma: user.locale (en GET /me y en whoami) es el idioma que la persona eligió en Tu cuenta: pt-BR, en o es; null es el automático, por el idioma del navegador o del dispositivo (sin ninguno de los tres, portugués). PATCH /me (tracker:write) con {"locale": "en"} lo cambia (null vuelve al automático) y devuelve {"locale": ...}. Vale para las pantallas, los correos, los avisos en el dispositivo y las apps, en todas las empresas de la persona (en automático, los correos y avisos siguen el último idioma que pidió el navegador o el dispositivo de la persona); no traduce lo que ya se escribió en tareas y conversaciones. Una app que muestra la interfaz en el idioma del dispositivo usa user.locale cuando no es null. Las frases listas que devuelve la API (el text de GET /notifications, de GET /inbox, de GET /issues/{ref}/history y la actividad de GET /people/{ref}, también en list_inbox, get_issue_history y get_person; los role_label del perfil también) vienen en ese idioma, con los nombres de estados y tipos de las plantillas traducidos; en automático, por el Accept-Language del pedido. En el MCP: set_language.
  • GET /me/deletion (tracker:read): lo que haría eliminar la cuenta ahora: email, can_delete (con blocker, el motivo, cuando no se puede: el dueño de la plataforma pasa el rol antes) y organizations, cada una con outcome (deleted: solo participa la persona y la empresa se elimina entera; owner_transferred: es la única dueña y new_owner pasa a ser dueño; left: solo sale). DELETE /me (tracker:write) con {"confirm_email": "<correo de la cuenta>"} elimina, sin vuelta atrás: borra nombre, correo, foto, login, tokens, conexiones y preferencias y la cuenta aquarela ID (aquarela_id: deleted, o pending cuando el soporte la termina allá); lo que la persona escribió queda con cada empresa como "Cuenta eliminada". El token deja de valer al instante. No existe en el MCP: eliminar la cuenta es solo de la propia persona, en el sitio, en la app o en la API.
  • GET /people/{me, id, correo o nombre} (tracker:read): el perfil de una persona de la empresa, como en la pantalla /people/<id>. person (id, name, email, active, organization_role y organization_role_label, member_since, url, el perfil en la pantalla, y avatar_url), all_projects (true para admins y dueños de la empresa, que valen en todos los proyectos), projects (name, prefix, slug, role, role_label), counts (open_assigned, open_qa, done_last_30_days), open_issues (las más recientes abiertas con ella como responsable: code, title, status, severity, project, updated_at, url) y activity (hasta 20 comentarios y cambios, los más recientes primero: kind comment o history, at, issue, text y, cuando cambió un valor, from y to). Solo entran los proyectos y las issues que ve el token; las horas registradas, solo para quien ve horas. Quien solo sigue los proyectos (parte interesada) ve solo a quienes participan en ellos, con email null. En el MCP: get_person.
  • Foto de la persona: avatar_url (en GET /me, GET /people/{ref} y author_avatar_url en los mensajes de la conversación) es GET /people/{id}/avatar (tracker:read, la imagen, con el token; 404 sin foto), null sin foto. La dirección cambia (?v=) en cada cambio, así que puede quedar en caché por la dirección: con la foto cambiada en la pantalla, el avatar_url nuevo llega en la próxima lectura. PUT /me/avatar (tracker:write) cambia la propia foto: multipart/form-data con la imagen en el campo avatar, o JSON {"image_base64": "...", "file_name": "foto.jpg"} (una imagen de más de 1,5 MB va en multipart). PNG, JPG o WebP hasta 2 MB; la pantalla y las apps recortan en cuadrado y mandan un JPG de hasta 512 px, y conviene hacer lo mismo (la foto aparece en un círculo). DELETE /me/avatar la quita (quedan las iniciales). La respuesta trae id, name y avatar_url. Quien comparte una empresa con la persona ve la foto. En el MCP: set_avatar.
  • GET /brand (tracker:read): las marcas para las apps: la empresa (organization, con slug, public_url y app_url como en GET /me) y sus logos (organization.square_logo_url y wide_logo_url), la firma "tracker by aquarela" con los archivos (product; product.by_url es adonde lleva el "by aquarela", el sitio de Aquarela, en una pestaña o en el navegador), las reglas y placements, dónde va cada una (place, organization: square, wide o null; product: icon, signature, signature_large, tab_title, header o null). tracker by aquarela nunca desaparece: donde la empresa ocupa la parte de arriba, la firma pasa al pie.
  • PUT /brand/logos/{square|wide} (tracker:write, admins y dueños): cambia el logo cuadrado (ícono, selector de empresa, menú contraído) o el horizontal (parte de arriba del menú, login, invitaciones, correos, portal). multipart/form-data con la imagen en el campo logo, o JSON {"image_base64": "...", "file_name": "logo.png"} (el cuerpo JSON va hasta 2 MB, así que una imagen de más de 1,5 MB va en multipart). PNG, JPG o WebP hasta 2 MB; el cuadrado con ancho y alto parecidos (al menos 64 px), el horizontal más ancho que alto. DELETE /brand/logos/{square|wide} lo quita. La respuesta trae la empresa y las dos direcciones. En el MCP: set_organization_logo.