Simafri Suite

Points another address at a mailbox: mail sent to it lands in that box, threads there and counts against the storage of the account. An alias has no password, no seat and no storage of its own, and the number one box may carry is limited; list_mailboxes gives the limit and what is already used.

Puts a person of the account on a mailbox, which is what lets them read it. This is how a company takes back the correspondence of someone who has left; it is recorded, and the box shows it to whoever is on it. A box may be held by several people.

Leaves a note on a thread for the people who work it: shown on the thread screen beside the messages, marked as internal, and in "notes" of get_conversation. It never reaches the correspondent: it is not sent, not quoted in a reply and not part of the mail. It is where the context goes when you hand a thread to a colleague, what you found, what was agreed, why you stopped. It does not change the status of the thread nor its place in the list. It is signed with the name of the person this connection acts for, when it acts for one. Up to 10000 characters. To leave the same note on several threads, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded.

Names a person of the account on a helpdesk queue, which is what lets them work it: they see the threads that arrived on that address, and none of the others. This is how a shared queue is split between colleagues, one department to each. Somebody whose rank already opens every queue is refused rather than given a grant that changes nothing.

Puts a person of the account in a team, whatever their rank. It opens no queue: they see the threads handed to the team only on the queues they already work, which add_queue_operator decides. A deactivated account is refused.

Sends a draft to the contact, with the text as given in "body" when you edited it. The draft keeps the original wording and the sent message keeps what actually left, so the two stay comparable afterwards.

Puts a colleague's name on a thread of a helpdesk queue: what says, to everyone working that queue, that this one is being dealt with and by whom. It hands over the WORK and not the access, so the thread stays readable by the whole team and nobody loses sight of it. Somebody who does not work that queue is refused rather than named on a thread they cannot open, and so is a deactivated account: put them on the queue first with add_queue_operator. Threads of a mailbox are refused too, a box being held rather than assigned. Name "team" instead of "person" to hand it to a team (list_teams names them): every member who works the queue sees it as theirs to take until one of them does, and a team none of whose members works the queue is refused. unassign_conversation gives the thread back to the queue. To hand several threads to the same colleague or team, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded.

Calls a scheduled message back before it leaves. Nothing is sent and nothing is lost: it becomes an unsent draft again, with its recipients, text and files, whose draft_id the answer gives (delete_compose_draft throws it away). Refused once the message is already leaving.

Opens an address to send a file to, so that a message can attach it without carrying it. Answers with an upload_id and an upload_url: PUT the bytes to that address in one request (no key, nothing to sign, for example `curl -T report.pdf "<upload_url>"`), then pass {"upload_id": "..."} in the "attachments" of send_email, reply_to_conversation, forward_conversation or approve_draft. This is the way to attach a real document: the inline base64 form asks you to write the whole file out yourself, which a PDF of a few pages overruns. One file per upload, good for one PUT, and it keeps for a day.

Opens a fiche for someone before any exchange has happened. An address the account already holds returns that contact as it stands, so calling it twice keeps one fiche.

Makes a folder in a mailbox, at the top or under another folder, to file threads in. Every holder of the box sees it, in the webmail and in their mail client. A name holds no "/", "*" nor "%", is unique among its neighbours, and at the top is none of the six every mailbox has.

Adds a doc to the playbook Iris reads, scoped to the brands and addresses you give it. Use it to record a price list, an argument that works or a rule to follow, once, where every future draft will find it.

Opens a team by its name; its slug comes from the name and never changes, even when the team is renamed. A name too close to one the account already has is refused. Put people in it with add_team_member.

Throws away a message that was started and will not be sent. Nothing was ever delivered, so nothing is lost but the text itself.

Deletes a thread and everything it holds: every message, the drafts written on it, and the files that came with them, down to the bytes they were stored as. This is FINAL and there is no trash to fish it back out of, so it is not the gesture for tidying an inbox: file_conversation with "trash" is, and it keeps the thread readable and restorable. Use this only when the record itself must not remain, and when the person asking knows that is what they are asking for. The contact fiche stays, and so does the rest of the correspondence with them.

Deletes a folder a person made and the folders under it. Their threads go to the Trash, where they stay readable and restorable for 30 days; nothing is deleted for good. The answer says how many went there.

Takes a doc out of the playbook, with every version it ever had. This is FINAL and there is no trash: Iris stops reading it from the next draft on. A doc that is merely out of date is better rewritten with update_knowledge, which keeps the previous version dated in its history.

Deletes a team. The threads handed to it go back to their queue with nobody's name on them; the threads one of its members took stay on that member's name.

Files a thread where you say: "archive" puts it away, out of the Inbox and kept for good; "trash" throws it away, where it stays readable and can be brought back; "inbox" brings it back from wherever it was; or "folder_id" files it in a folder a person made (list_folders gives them), which becomes its home. One thread sits in one place, so filing it somewhere takes it out of where it was; a reply brings a thread back to the Inbox without taking it out of its folder. This is the gesture for tidying a mailbox, and "trash" is what "delete this thread" almost always means: nothing is lost for 30 days, after which the Trash deletes it for good, and delete_conversation is the other, immediate and final thing. It does not file spam: report_spam is that gesture, because filing as spam also blocks the sender. A thread of a helpdesk queue has the Trash as its one folder: "trash" throws it away (a spam, a phishing attempt, a prospecting mail nobody answers) and "inbox" brings it back to the view its status belongs to; "archive" is refused there, closing a case being how a queue puts it away. Filing never changes where a thread STANDS: a notice thrown in the Trash is still "open", among what is left to do. Give "status" (and "deal_stage") to settle that in the same gesture, as set_conversation_status would: "trash" with "closed" tidies away what nobody answers, "archive" with "answered" or "closed" puts away an exchange that is over. The status is recorded first, so a status refused leaves the thread where it was, and a thread that then cannot be filed answers that its status was recorded and why it stayed put. To file several threads in the same place, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of re…

Passes the last message of a thread on to someone else: they receive the text quoted under its own header, with the files it carried attached again. Their answer opens a thread of its own, so forwarding to the account support address is how a message reaches the support queue, in that direction only.

Reads a file attached to a message and gives back its CONTENT. Text comes back as text, whatever the sender labelled it: a CSV, an XML, a JSON, a Markdown or a log read as text even when they arrive as application/octet-stream. An image comes back as the image itself, a PDF comes back as the text it holds, which is how an invoice, a quote or a contract is read, and a .gz or a .zip is opened to give the text it holds, which is how a DMARC report is read. An office document comes back as its text, which is how a product sheet, a price list or a deck is read: a .docx as its paragraphs and tables in order (headings marked with #, list items with - or their number, tables as Markdown tables), a .xlsx as its cells sheet by sheet, tab-separated, one line per row, dates shown as dates, and a .pptx slide by slide; its pictures follow as images when, with the text, they fit in 1048576 bytes decompressed, and are otherwise listed in "document.images" with their name and size. Its macros are never run. A PDF with no text layer, a scan for instance, says so in "note" and gives the address instead: its pages hold pictures rather than words. What stays binary comes back as its media type, its size and the address to fetch it whole, and says in "note" that its content is not restituable. Above 1048576 bytes (16777216 for an office document), and for an archive holding another archive or for an archive or an office document holding more than 1048576 bytes once decompressed, the answer carries that address rather than the content. Every answer also carries "download_url", and shows it in its last block: the original FILE, byte for byte, under its own name and media type, to GET with no key and nothing to sign, once, within 15 minutes (for example `curl -o fiche.docx "<download_url>"`). That is the way to turn what you were shown into a file you have: save the photos of a document for a site, hand a PDF to another tool, or fetch a file too large to come back inline. Call get_attachme…

Reads one contact whole: their fiche, the addresses they write from and where each field came from.

Reads one thread whole: every message in order with its direction, its language and its attachments, the contact fiche, the mailbox the thread arrived through, the draft awaiting review when there is one, and in "notes" what the team left on the thread for each other, oldest first, with who wrote each one. Notes are never part of "messages" and were never sent to anyone. A message the mailbox sent carries "delivery" when the mail system tracked it: per recipient (Bcc included), "state" is "delivered" (accepted by the recipient's server, which says nothing of the inbox or of reading), "deferred" (retried by itself for five days), "bounced", "returned" (accepted, then a non-delivery report came back) or "expired", with the server's own "remote_reply" and a "reason" in plain words. When the thread was filed as it arrived, "filed_reason" says why: "spam_filter" for the filter's verdict, "blocked_sender" for a sender the account had reported, and "spoofed_own_domain" for a mail showing one of the account's own domains whose DMARC check failed, which lands in Spam in a mailbox (mark_not_spam takes it back out) and, on a helpdesk queue, in the Trash with its ticket closed (file_conversation with "inbox" brings it back, open). Read this before writing an answer. To read several threads, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded.

Reads the customer card of a helpdesk ticket: what the account's own system (its client area, CRM or ERP) knows about the correspondent, asked live by their address, such as their account, their services and when they renew, and what they owe. "status" says "found" with the card, "not_found" when that system does not know them, "unavailable" when it did not answer (ask again later, it says nothing about the customer), "unverified" when it was not asked because the latest message names its correspondent through a Reply-To that nothing authenticates (nothing proves that person wrote, so do not discuss their account by email), and "none" when the account has no such system connected or the thread is somebody's mailbox. Read it before answering a customer about their account, a renewal or an invoice.

Reads the settings of the account, starting with whether an incoming message has Iris draft an answer on its own. "own_domain_spoofs" says what the account does with a mail that shows one of its own domains and fails DMARC: "filed" when such a mail goes to Spam (to the Trash, closed, on a helpdesk queue) as it arrives, and "exempt_senders" for the addresses of the account that keep arriving normally although they fail. It is read here, and the support team changes it on request.

Opens an access for a colleague without a password: an invitation goes to send_to, and whoever opens it chooses the password from its link, which opens for seven days and once. The link is never shown here, you included, and the record names where it went. send_to is the person themselves at an address they already read, or the box of whoever sets up the team's access. A mailbox of this platform is accepted only when an active person already signs in to it; one nobody can open yet, such as the new login itself, is refused, and so is a support queue. Called again for somebody who has not answered yet, it sends a new invitation and the previous link stops opening; somebody who already chose a password is refused, as they change it themselves. Only on an account that is not held at the shop, and never above manager.

Lists the addresses whose mail this account files straight into Spam, most recently blocked first, with the day each was blocked. A block is what report_spam leaves behind, so this is where a rule the account is living under becomes visible again: a sender blocked from a thread long since deleted appears here and nowhere else.

Lists the brands of the account, its subdivisions, each with the slug the other tools take.

Lists the messages begun on the account addresses and never sent, last written first, with their recipients, subject, text and files. These are unsent texts, not the answers Iris wrote for review, which list_drafts holds.

Lists the contacts of the account with their fiche, most recently seen first, and searches them by name, company or address.

Lists threads, most recently updated first, with the contact, the subject of the mail and the one the team gave the thread ("team_subject", null until rename_conversation gives one), the ticket number of a helpdesk case (what the client quotes, null on somebody's mailbox), the status, where the thread stands in the pipeline, who is handling it, whether a draft is waiting for review, the folder each sits in and whether you have read it. Each thread also says since when its contact has been waiting for our answer ("waiting_since", their oldest message still unanswered, null when nobody waits), and when the last reply came and from which side ("last_reply_at", "last_reply_by"): the two figures a helpdesk queue is watched by, to tell which tickets drag. Name a "box" to read ONE mailbox exactly as its screen shows it: its Inbox by default, another folder on demand, and "unread" for the bold rows alone. Without a "box" it lists the whole account by pipeline status instead, which is a different question: a thread sitting unread in a mailbox has a status like any other, so a list by status is not the list of what is waiting to be read.

Lists the answers Iris has written, with the thread each belongs to, the contact it goes to and the text as it stands. Filter on "pending_review" for the review queue.

Lists the folders the people of a mailbox made in it, beside the six every mailbox has (inbox, sent, drafts, spam, trash, archive), each with its id, its name, its full path ("Clients/LCS") and its parent. The ids are what list_conversations, search_conversations and file_conversation take, and what update_folder and delete_folder act on.

Lists the playbook docs of the account with their full content: this is the material Iris reads before drafting, and the place to look when an answer needs to say what the house does.

Lists the mailboxes of the account: each one with the people who hold it, the other names that deliver into it and the storage its plan entitles the account to, which every box of it shares. It says who is on a box, never what is in one.

Lists everyone on the account: how they sign in, the rank they hold, and how far they see into the mail. An owner and a manager work every helpdesk queue, which is said as works_every_queue; anyone else works the queues named on them and nothing else. It says who works where, never what any of it holds. A rank is not written from here: for a client of Simafri Suite it is held at the shop and restated at every sign-in.

Lists the messages given a "send_at" that have not left yet, soonest first: when each leaves (in the zone of the person you act for), from which address, to whom, the subject and text, and the thread an answer goes into. A message that has left is no longer here but in its thread. One that could not leave stays, with state "failed" and the reason, until it is cancelled.

Lists the inbound addresses of the account, each with the block that closes what is written from it and, for a mailbox, the other names that deliver into it. Sending from any of these is what brings the answer back into the mailbox.

Lists the addresses that pressed "this is spam" on this account's mail, with the day and the label their provider gave it. The account writes to none of them, and it does so SILENTLY: a message to one of these addresses is stopped before it leaves, with no bounce and nothing in the thread to see. So this is the list to read when a mail seems to have gone nowhere and nothing said why.

Lists the teams of the account, the administrative team or the technical one for instance, each with its slug (what assign_conversation and the other team tools take) and who is in it. A team is a way of handing a thread to several people at once; it opens no queue, so a member only ever sees the threads of the queues they work.

Puts a thread the filter or someone else filed as spam back into the Inbox of its mailbox, and unblocks its sender. A thread that is not in Spam is left where it is, and nothing is unblocked. To take several threads out of Spam, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded.

Clears the bold on a thread for YOU, exactly as opening it on screen does: a colleague reading the same shared mailbox keeps their own. Reading a thread with get_conversation does not do this by itself, on purpose: fetching a mail is not the same as having read it. A message arriving after this call turns the thread bold again. To clear the bold on several threads, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded.

Puts a thread back among the bold rows, for you alone: what you want to come back to. A colleague sees no change. To put several threads back among the bold rows, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded.

Merges a helpdesk ticket into another of the same contact, for the client who wrote again beside their case rather than in it. Everything it held moves to the ticket named by "into": its messages, their files, its notes, its drafts. Its number keeps leading to the merged case, so the client's next reply quoting it lands there. The ticket merged away is gone, a note on the one that stays says so (with your reason, when you give one in "note"), and a draft that was waiting on it is set aside. It cannot be undone. Both must be tickets of a support queue you can open, with the same contact; a mailbox thread is refused.

Reads the account mailboxes right away instead of waiting for the next scheduled round, and answers with what came in. Call it when you expect a message that has not appeared yet.

Turns a draft down and sends nothing. The thread stays open for another answer, by Iris or by a person.

Stops an address delivering into a box. What already arrived through it stays in the box, and each message still says which name it came in on.

Takes a person off a mailbox: they stop reading it from that moment. Nothing is deleted, and a box left with no holder keeps receiving and keeps everything it holds. Recorded like the other direction.

Takes a person off a helpdesk queue: they stop seeing its threads from that moment. Nothing is deleted, and a queue nobody is named on keeps receiving and is still worked by the owners and the managers of the account.

Takes an address off the list above, so this account can write to them again. Weigh it before calling it: the row means a person pressed "this is spam" on mail from this account, and writing to them again is what turns a complaint into a sending reputation the whole platform shares. Call it when there is a reason to believe they want to hear from this account again, said by them, and not merely because a message would not leave. An address holding no suppression answers that there was nothing to lift.