DocumentationEveryday use
Rust · 0.1.0
Attachments
Add files, check upload results and understand where their access comes from.
Upload and attach
Add an attachment through the editor or manage files in the Attachments page. Wait for upload completion before leaving the workflow. File size limits come from instance settings and may also be constrained by a reverse proxy. If a large upload fails, confirm both layers before retrying repeatedly.
Linking is an explicit operation
The API can create a file and set the attachment list on a memo. SetMemoAttachments replaces the complete list rather than appending one item. Send the entire intended set when using this operation. Omitting an existing attachment deletes its metadata and invokes cleanup of its stored bytes; an empty set removes all attachments. Keep a backup before replacing the set. File reads still require the appropriate memo/file authorization; knowing an attachment URL is not a general permission grant.
Keep a recoverable copy
Database records and local/S3 bytes may be stored separately. A file can be unavailable because its storage object is missing even when its metadata still exists. Include both in backups, and verify a downloaded sample after restoration. Removing an attachment from a memo can delete the attachment itself; do not treat it as a reversible unlink.
Verify an attachment from upload to download
Prepare a small text file containing a unique line. Open a new private memo, add the file through the editor’s attachment control, wait for upload completion, then save the memo. Reload and open the attachment from that saved memo. Download it and compare the unique line. Keep the original local file until the round trip succeeds. An uploaded file is not proof that the memo linking/save step completed.
Recover from an interrupted upload safely
If the tab closed or the network failed, reopen the memo and inspect its existing attachment list before uploading again. A 413 suggests an application or proxy size limit. A readable memo with an unavailable file suggests missing storage bytes or storage connectivity; a file denied to another account suggests authorization and needs a separate access test. Do not remove an existing attachment merely to retry a download: removal can delete its metadata and underlying bytes.
Preserve both members of a Live Photo
For API clients replacing a memo’s attachment list, inspect attachment grouping before building the new set. An existing APPLE_LIVE_PHOTO pair must be retained in full or intentionally removed in full. If only one member is requested, the memo replacement logic removes the incomplete pair from the retained set; a successful update can delete both members, including the one you thought you retained. This is not the same as a dedicated attachment-delete endpoint rejecting a partial-group deletion. Keep both attachment resource names and verify the full returned set before discarding a backup.