REST API

Account, people and brand

The token's person, profiles, photos, logos and account deletion.

  • GET /me (tracker:read): the person (user, with id, name, email, locale and avatar_url), the organization, the projects with the role in each one, the token and the version of tracker (server). Each company in organizations has slug, public_url (the company's public address, like https://suaempresa.centraldeajuda.ia.br: the root is the help center, /status the published status page and /suporte/... and /ideias/... the help desk portal and the idea boards; null with the public address turned off), app_url (the company in tracker, null without a per-company subdomain) and brand with square_logo_url and wide_logo_url (public, null without the logo). whoami returns public_url too.
  • Language: user.locale (in GET /me and whoami) is the language the person chose in Your account: pt-BR, en or es; null is Automatic, following the browser's or device's language (with none of the three, Portuguese). PATCH /me (tracker:write) with {"locale": "en"} changes it (null goes back to Automatic) and returns {"locale": ...}. It applies to the screens, e-mails, device notifications and apps, in all of the person's companies (on Automatic, e-mails and notifications follow the last language the person's browser or device asked for); it doesn't translate what was already written in tasks and chats. An app that shows its interface in the device's language uses user.locale when it isn't null. The ready-made sentences the API returns (the text of GET /notifications, of GET /inbox, of GET /issues/{ref}/history and the activity of GET /people/{ref}, also in list_inbox, get_issue_history and get_person; the profile's role_label too) come in that language, with template status and type names translated; on Automatic, by the request's Accept-Language. In the MCP: set_language.
  • GET /me/deletion (tracker:read): what deleting the account would do now: email, can_delete (with blocker, the reason, when it can't: the platform owner hands over the role first) and organizations, each with outcome (deleted: only this person is a member and the whole company goes away; owner_transferred: they're the only owner and new_owner becomes the owner; left: they just leave). DELETE /me (tracker:write) with {"confirm_email": "<account e-mail>"} deletes it, with no way back: it erases name, e-mail, photo, login, tokens, connections and preferences and the aquarela ID account (aquarela_id: deleted, or pending when support finishes it there); what the person wrote stays with each company as "Deleted account". The token stops working immediately. Not available in the MCP: deleting the account belongs to the person alone, on the website, in the app or in the API.
  • GET /people/{me, id, e-mail or name} (tracker:read): the profile of a person in the company, as on the /people/<id> screen. person (id, name, email, active, organization_role and organization_role_label, member_since, url, the profile on screen, and avatar_url), all_projects (true for company admins and owners, who count in every project), projects (name, prefix, slug, role, role_label), counts (open_assigned, open_qa, done_last_30_days), open_issues (the most recent open ones with them as assignee: code, title, status, severity, project, updated_at, url) and activity (up to 20 comments and changes, most recent first: kind comment or history, at, issue, text and, when a value changed, from and to). Only the projects and issues the token sees are included; logged hours, only for those who see hours. Someone who only follows the projects (stakeholder) sees only the people in them, with email null. In the MCP: get_person.
  • Person's photo: avatar_url (in GET /me, GET /people/{ref} and author_avatar_url in chat messages) is GET /people/{id}/avatar (tracker:read, the image, with the token; 404 without a photo), null without a photo. The address changes (?v=) on every swap, so it can be cached by address: with the photo changed on screen, the new avatar_url arrives on the next read. PUT /me/avatar (tracker:write) changes your own photo: multipart/form-data with the image in the avatar field, or JSON {"image_base64": "...", "file_name": "photo.jpg"} (images over 1.5 MB go as multipart). PNG, JPG or WebP up to 2 MB; the screen and the apps crop to a square and send a JPG of up to 512 px, and it's worth doing the same (the photo shows in a circle). DELETE /me/avatar removes it (the initials remain). The response has id, name and avatar_url. Anyone who shares a company with the person sees the photo. In the MCP: set_avatar.
  • GET /brand (tracker:read): the brands for the apps: the company (organization, with slug, public_url and app_url as in GET /me) and its logos (organization.square_logo_url and wide_logo_url), the "tracker by aquarela" signature with its files (product; product.by_url is where "by aquarela" leads, Aquarela's website, in a tab or the browser), the rules and placements, where each one goes (place, organization: square, wide or null; product: icon, signature, signature_large, tab_title, header or null). tracker by aquarela never disappears: where the company takes the top, the signature moves to the footer.
  • PUT /brand/logos/{square|wide} (tracker:write, admins and owners): changes the square logo (icon, company switcher, collapsed menu) or the wide one (top of the menu, sign-in, invites, e-mails, portal). multipart/form-data with the image in the logo field, or JSON {"image_base64": "...", "file_name": "logo.png"} (the JSON body goes up to 2 MB, so images over 1.5 MB go as multipart). PNG, JPG or WebP up to 2 MB; the square one with similar width and height (at least 64 px), the wide one wider than tall. DELETE /brand/logos/{square|wide} removes it. The response has the company and both addresses. In the MCP: set_organization_logo.