Files

Real bytes, for twins whose vendors hold files.

Upload real bytes with POST /veris/files to a twin whose vendor holds files: a document in Drive, a PDF in Dropbox, source in a GitHub repository. Those are bytes rather than a string in a column, so they do not go through /veris/data.

Seed the owner first

A file belongs to something: a user, a folder, a repository. Seed that owner first, then upload.

$CONTROL_URL is one twin’s control URL, printed by veris sandbox services get — see the control plane.

curl -X POST --data-binary @report.pdf \
  "$CONTROL_URL/veris/files?path=Inbox/report.pdf&owner=<owner id>"

A whole tree at once, as a zip:

curl -X POST --data-binary @fixtures.zip \
  "$CONTROL_URL/veris/files?prefix=Client%20Uploads&owner=<owner id>"

mode=merge adds to what is there and is the default. mode=replace clears the prefix first.

Reading bytes back

Read them through the vendor’s own download endpoint, exactly as your code would. The twin returns the exact bytes.

/veris/data does not return file contents. It shows the SHA-256 of the bytes instead.

That hash is also how you check an upload:

shasum -a 256 report.pdf

Compare it against what /veris/data shows. null means there are genuinely no bytes.

A 404 from /veris/files

A twin whose vendor has a file tree serves /veris/files. A twin whose files are attachments to something else takes bytes only through the vendor’s own upload API, and posting here returns a 404 saying so.

That twin’s /veris/manual says which it is, along with anything specific about how it stores them.

Limits

An import over one of these is refused with the number, and nothing is partially written.

Files in a promoted world

Files are carried into a promoted baseline along with the rows. A baseline holding many files takes a few minutes to boot the first time while they are copied in. See Reset, snapshot, baseline.

Read next

• Seeding your own
• Reset, snapshot, baseline