SDK · @manybases/js
@manybases/js — storage
Upload, list and delete files. Three methods, each returning { data, error }.
| Method | Calls | Returns |
|---|---|---|
upload(body, { name, contentType?, visibility? }) | POST /v1/files | a StoredFile |
list({ limit?, cursor? }) | GET /v1/files | { data: StoredFile[], cursor, error } |
remove(id) | DELETE /v1/files/:id | { id, deleted: true } |
A StoredFile is { id, name, size, content_type, visibility, url, created_at }. url is an absolute signed link to the content: valid one hour for a private file, without expiry for a public one. There is no url(id) method and no route to read a file by id — the URL is a field, and re-listing gives a fresh one.
const { data, error } = await mb.storage.upload(file, { name: file.name, contentType: file.type });
// data.url → the link to serveUploads need a known length#
POST /v1/files requires a declared Content-Length, and a script cannot set that header by hand. So upload accepts a Blob, File, ArrayBuffer or Uint8Array — bodies whose length the runtime knows — and refuses a stream before the call, naming the reason. A plain string is refused too: pass bytes. The 25 MB cap is enforced by the API; in a browser the bytes are pushed before the 413 comes back.
Visibility#
visibility defaults to private: the file behaves like a row on the prive preset, and its link expires. public behaves like the partage preset, and its link does not expire — deleting the file is the only way to revoke it. Whoever holds a link can read the file, with no sign-in.
Two uploads, two files#
POST /v1/files ignores idempotency keys: uploading the same file twice creates two files with two ids. Hold uniqueness through the name you choose.