Conversaciones

GET /threads?folder=inbox. Pasar query busca en el mismo índice local. Las palabras sueltas deben aparecer todas, y cada una coincide de forma laxa, ignorando mayúsculas, acentos y separadores, así que min encuentra "Benjamin". Una frase entrecomillada coincide tal cual está escrita salvo por mayúsculas y acentos, así que "ben jamin" no encuentra "Ben-Jamin". Las palabras de relleno como the o emails se descartan de una lista de palabras sueltas cuando queda algo más que buscar. Operadores como from:, to:, subject:, label:, is:unread, has:pdf, after:2026/01/31 y newer_than:7d la acotan, y OR, los paréntesis y un - inicial los combinan. Los destinatarios se guardan como una sola lista sin roles y nunca contienen un Bcc, así que cc: lee el mismo campo que to: y bcc: no coincide con nada propio. from:me es el correo que enviaste, y to:me es el correo que lleva una de tus propias direcciones, alias incluidos, entre sus destinatarios o como dirección a la que se entregó.

Las palabras y los operadores from:, to:, cc:, subject: y body: leen el mensaje más nuevo de cada conversación: su remitente, sus destinatarios, su asunto y los primeros 4.000 caracteres de su cuerpo. filename: y has: leen todos los adjuntos de la conversación entera, y label:, in: y is: leen la conversación entera. folder sigue aplicándose salvo que la consulta nombre una carpeta con in:, o con un is: que sea una carpeta como is:sent, y in:anywhere busca en todas las carpetas, tanto por sí solo como junto a otros términos. Un listado de borradores es la excepción y se queda en borradores diga lo que diga la consulta.

Un valor que la búsqueda no puede usar se ignora en lugar de acotar, así que una errata en un valor amplía el resultado en vez de vaciarlo: category:, larger:, smaller:, size:, messagesize:, list:, rfc822msgid:, received:, sent:, las palabras de categoría como is:promotions, una palabra de has: que no nombre ningún tipo de adjunto, un importance: distinto de high o low, una fecha ilegible y una duración cuya unidad no sea h, d, w, m o y. Un nombre de operador que no conoce, project: por ejemplo, se busca como texto plano. Las fechas leen la actividad más reciente de la conversación, en UTC, con after: incluyendo el día que nombra y before: excluyéndolo; escribe una como YYYY/MM/DD, YYYY-MM-DD, YYYYMMDD, un año a secas, o segundos o milisegundos de epoch.

GET /threads/{id} devuelve todos los mensajes de la conversación, no solo el más reciente, junto con sus etiquetas y si algo en ella está sin leer.

Esta API ni cifra ni descifra. No puede abrir un mensaje que otra persona cifró, y no puede enviar uno cifrado. Una petición que lleva un marcador de cifrado se rechaza con un 422, porque las únicas superficies que pueden ponerlo son las que tienen las claves, y ningún cliente de la API tiene una clave. Lo que sí hace es RECONOCER un sobre sellado a la entrada, a partir del Content-Type de nivel superior y de nada más, y después decirlo en el mensaje.

OpenEmail sí guarda claves ahora, y vale la pena ser exactos sobre cuál mitad y dónde. El dueño de un buzón genera una identidad OpenPGP en su navegador y publica la clave PÚBLICA en un directorio que otros remitentes de OpenEmail autenticados pueden resolver. La mitad privada se crea en ese navegador, nunca se envía aquí y nunca es recuperable, así que nada en esta API puede descifrar nada, y ninguna petición de soporte, requerimiento judicial o copia de seguridad nuestra produce una clave que pudiera hacerlo. La aplicación web ya puede ABRIR un mensaje PGP/MIME o PGP en línea cuando la clave está en el navegador de quien lee, pero ese descifrado ocurre en la pestaña y su texto claro nunca se escribe de vuelta: el mensaje almacenado sigue siendo texto cifrado, y ninguna respuesta de esta API lleva jamás el texto abierto. La aplicación ya puede sellar un mensaje nuevo en el navegador y enviarlo: el compositor cifra hacia las claves publicadas de los destinatarios y el correo sale como PGP/MIME. Esta API sigue sin poder sellar nada, así que el campo de abajo describe tanto el correo que cifró otra persona como el correo sellado en una pestaña de OpenEmail.

Eso merece un campo por lo que había antes como alternativa. Un mensaje sellado no guarda cuerpo legible, así que decodedBody vuelve como "", los mismos bytes que un mensaje que realmente no tenía contenido. encryption es lo que te permite distinguir los dos casos antes de actuar sobre uno, y es una afirmación sobre el sobre y no una verificación: ver que un mensaje está sellado no es lo mismo que haberlo abierto.

{    "object": "thread",    "id": "thread_2f9b…",    "messages": [      {        "id": "msg_7c41…",        "subject": "Q3 numbers",        "decodedBody": "",        "encryption": {          "format": "pgp-mime",          "detectedAt": "2026-08-30T09:14:22.117Z",          "rawRetained": false,          "parts": [            { "index": 0, "attachmentId": "msg_7c41…-0", "role": "version" },            { "index": 1, "attachmentId": "msg_7c41…-1", "role": "ciphertext" }          ]        }      }    ]  }

Solo los tres formatos sellados cambian algo, y el cambio ocurre en la ingesta y no en esta respuesta. Todo lo que habría leído el cuerpo se aparta, en lugar de leer texto cifrado e informar de un resultado que no podría haber obtenido:

• —La búsqueda sobre el cuerpo. El mensaje se indexa con un fragmento de cuerpo vacío, así que sigue encontrándose por remitente, asunto, dirección y etiqueta, y no por nada de su interior.
• —La pasada sobre el cuerpo del evaluador de phishing. El veredicto sigue llegando y dice lo que no pudo hacer: risk.signals lleva body-encrypted y risk.aiChecked es false.
• —La comprobación de autoría por IA, que se abstiene en lugar de adivinar: aiWritten.level es unknown y aiWritten.skipped es encrypted.
• —Las condiciones sobre el cuerpo en las reglas. Las condiciones de sobre y de cabecera se ejecutan exactamente igual que antes; una regla que preguntaba por el cuerpo se registra como no evaluada en lugar de contarse como no coincidente, porque "no coincidió" y "no se pudo leer" son respuestas distintas.
• —La importación de invitaciones de calendario. La invitación está dentro del texto cifrado, y construir un evento a partir del sobre pondría una entrada equivocada en un calendario real.
• —Los resúmenes de conversación y los embeddings, para la conversación entera. Basta con una respuesta sellada. Un resumen es la lectura que un modelo hace del texto claro guardada como metadato en claro, que es el único punto de esta canalización donde un cuerpo se filtraría a un almacén que nadie considera un cuerpo.

Todo lo que no necesita el cuerpo queda intacto:

• —DMARC, DKIM y SPF. Eso se lee de Authentication-Results, que el texto cifrado no oculta, así que un mensaje cifrado sigue obteniendo un veredicto de autenticación real en lugar de ninguno.
• —El agrupado en conversaciones, el archivado de spam y la lista de bloqueo: todo trabajo de sobre y de cabecera.
• —Los adjuntos. La parte con el texto cifrado se queda en attachments, llamada encrypted-message.asc cuando llega sin nombre, y se descarga por el endpoint de abajo. Es exactamente lo que el lector de la aplicación web descarga y descifra en el navegador; para un cliente de la API, que no tiene clave, esa descarga sigue siendo la única forma de leer el correo. Ábrelo en un cliente que sí tenga una.
• —Un mensaje firmado no pierde nada de esto. Todas las comprobaciones anteriores siguen ejecutándose sobre él, y no se retiene nada, que es por lo que la lista de sellados tiene tres formatos y no cinco.

PATCH /threads/{id} acepta read, addLabelIds y removeLabelIds. El estado de lectura es una etiqueta en todos los backends que este producto soporta, así que fijar read y mover etiquetas en una sola llamada mantiene el orden determinista.

{ "read": true, "addLabelIds": ["USER_INVOICES"] }

GET /threads/{id}/messages/{messageId}/attachments devuelve cada adjunto con filename, contentType, size y content en base64. content es una cadena vacía cuando no se pudieron encontrar los bytes almacenados, así que comprueba su longitud antes de decodificar.