Attaching Files to a Row

An attachment field keeps files with the row they belong to: the receipt behind a transaction, the contract behind an invoice, a statement PDF behind a balance.

An attachment cell holds several files, in an order you control. There is no single-file mode to choose between.

The short version#

• One attachment cell can hold up to 10 ordered files, each up to 25 MB.
• Files upload independently, so one failure can be retried without restarting the others.
• The cell membership commits atomically only after the uploads are ready.
• Files are private workspace data. Rows expose metadata, never storage keys or public URLs.

Adding files#

Click an attachment cell and drop files in, or pick them from your computer. You can add several at once.

Each file uploads on its own and shows its own progress. That matters when one of them fails: the others still land, and the one that failed offers Retry by itself, naming what went wrong. A file that is still uploading can be cancelled on its own.

Files only join the row once the batch is committed, and they are committed together. A half-finished drop never leaves a cell in a state where some files are attached and the record of what is attached disagrees with what is stored.

Everything is re-checked on the server when the cell commits — how many files, their types, their sizes, and that they belong to your workspace. Passing the check in the browser is not what grants the write.

Ordering, previewing, downloading#

• Reorder files with the move-earlier and move-later controls on each one. The order is part of the cell's value and is what the API returns.
• Open a file to preview it. Images and PDFs render inside the preview dialog; anything else says so and offers the download instead.
• Download is available from the preview.

Caps#

Both are refusals. Dropping an eleventh file, or a file over the size limit, fails and says which limit it hit — nothing is silently dropped.

Total attachment storage is a plan limit, listed on the pricing page and on the Tables overview.

How the bytes are protected#

Attachment files are never public.

• Uploading and reading are authenticated and scoped to your workspace. There is no unguessable-URL trick that would let a link leak the file.
• Row data and API responses never contain a storage key or a public URL — only the file's name, type, size and position.
• Previews render from an authenticated in-memory copy inside the dialog, and downloads are always served as downloads rather than as pages your browser might execute.
• Deleting the row, the table, or the workspace removes the files with it.

Attachments over the API#

An attachment cell cannot be written by sending a value in a row write; it has its own operations, because a file has identity, bytes and a position that a value in a row cannot carry. Sending one in a row write is refused with a typed error rather than ignored.

Upload the file first, then commit the field's file list. Reading a row gives you each file's metadata plus a total and a hasMore flag; download the bytes with the attachment endpoint. See Tables over the API.

Uploads that are never attached to a row are swept away after 24 hours.

Where to go next#

• Tables over the API — the upload-then-commit sequence.
• Field types in a table — the rest of the field vocabulary.