openemail files

Resolves one page of the Files page: every attachment the mailbox holds, sent and received, and every file uploaded to it, with its name, type, size, the address it came to, the thread it belongs to and whether it can be deleted.

Only an upload that nothing depends on can be deleted, and its deletable is true. Every other row has a usage saying what keeps it: received, sent, linked for an upload that went out as a download link that still works, or scheduled for one attached to a message that has not gone out yet.

A key limited to particular addresses or domains sees only the files that arrived at them, the same boundary the thread list uses, so it does not see files uploaded for the whole workspace. A deleted file is not listed.

The index starts from the day it shipped, so an older mailbox lists what has arrived since. Older attachments are still on their messages, where threads.listAttachments reads them.

Add --all to walk every page: a table on a terminal, one JSON object per line when piped or with --ndjson, and one { items, hasMore, nextCursor } document with --json. --max <n> stops after that many items.

Resolves one file: its name, type, size, whether it was sent, received or uploaded, the address it came to, the thread and message it belongs to, and whether it can be deleted. download fetches its bytes.

deletable is true only for an upload that nothing depends on. Otherwise usage says what keeps it: received or sent for a file that came in or went out on a message, linked for an upload that went out as a download link that still works, and scheduled for one attached to a message that has not gone out yet.

Returns the numbers on the Analytics tab of the Files page in one request: how many files the mailbox holds and how many bytes they take, in all and split into received, sent and uploaded, the file types and the addresses taking the most space, how many files arrived on each of the last 30 days, and the download links still working with how often they were fetched.

Deleted files are not counted. A key limited to particular addresses or domains counts only the files that arrived at them, so files uploaded for the whole workspace are left out of its numbers.

Resolves with the file exactly as it is stored, the same bytes the Download action on the Files page saves. The response carries the file's own Content-Type and name.

Resolves one page of the download links made for this file, newest first. A large attachment sent from OpenEmail travels as a link rather than inside the message, and each send makes a link of its own. Every row says how often it was fetched, when last, and whether it was revoked. While one of its links still works, an upload cannot be deleted.

A file attached inside a message has no links, because nothing records when those are opened.

Add --all to walk every page: a table on a terminal, one JSON object per line when piped or with --ndjson, and one { items, hasMore, nextCursor } document with --json. --max <n> stops after that many items.

Makes a public download link for the file and resolves with it. Anybody holding url can open the file without signing in, which is how an image or a document is referenced from an email or a web page. Each call makes a new link with its own download count, and a link keeps working until it is revoked with revokeLink or the file is deleted.

The link lives on the files host of --domain when that domain has one set up, such as files.acme.com, else on the files host of the address the file belongs to, else on the OpenEmail API address. A file that came in or went out on a message is copied to public storage first. Programs and scripts are refused with 422 file_unshareable.

Stops a public link from working, for good, including in mail that already went out with it, and resolves with the link, revokedAt set. Revoking a link that is already revoked resolves with it unchanged, so the call is safe to repeat. An unknown link is a 404.

Makes the file private, as Make private on the Files page does: every public download link to it stops working at once, including the ones in mail that already went out. Resolves with revoked, how many links were still working. The file itself stays, and createLink can publish it again at a new link.

A key limited to particular addresses reaches only the files that arrived at them, and any other file is a 404.

Stores the bytes as a new file, the way the Upload button on the Files page does, and resolves with it: direction is uploaded, usage is null and deletable is true. Attach it to a send as { fileId } in emails.send, which is how a file larger than the inline cap goes out.

data is a Blob, an ArrayBuffer or a Uint8Array, sent as the request body. The name travels as the filename query parameter, and it is cleaned rather than refused: characters a file name cannot hold become _, and a name longer than 255 characters is cut, keeping its extension. The type is --content-type, or a Blob's own type when that is left out, and application/octet-stream without either. A value that is not shaped like a MIME type is stored as application/octet-stream too.

A key limited to particular addresses or domains uploads to the first address it holds, which becomes deliveredTo. An unlimited key uploads for the whole workspace and deliveredTo is null, so a narrowed key never reaches that file afterwards.

Removes an uploaded file: its bytes are deleted from storage and it leaves the Files page. The row stays, marked deleted, so the index knows the file existed. There is no undo.

Only an upload that nothing depends on can be deleted, the files whose deletable is true. A file that was received or sent stays with its message, and so does an upload that went out as a download link that still works or is attached to a message that has not gone out yet. Those are refused with 409 file_in_use, and the message names the file and says why. An upload that was sent inside a message can still be deleted, because the message keeps its own copy, which is listed as a separate sent file.

deleteMany deletes up to 100 in one call and reports the ones it kept instead of failing.

Deletes every file in ids that can be deleted, the way delete deletes one, and reports the rest instead of failing. It is what selecting several files on the Files page and pressing Delete does.

Only an uploaded file that nothing depends on can be deleted. A file that was received or sent stays with its message, and so does an upload that went out as a download link that still works or is attached to a message that has not gone out yet. Each of those comes back in kept with its usage and a reason in plain words. An id that is unknown, already deleted or outside the addresses a narrowed key holds comes back in missing. The rule is checked again at the moment of deleting, so a file that became used in between is kept.

There is no undo.