file-upload

Upload files by posting multipart/form-data to the web-editor v2-upload endpoint to get a tempStoredFileName, then call bucket-files/create-relative to obtain a storedFileUUID. Pass the resulting file descriptor to downstream apps or dashboard cells.

Use the multipart flow on the same v2-upload endpoint: start with action=start to get part URLs, PUT each chunk with up to 3 retries, then finish with action=finish including parts, uploadingId, and tempStoredFileName.

No, never store base64, bytea, or data URLs in isolated SQL, even as an MVP. Ordinary SQL write paths are only reliable around 100-150 KB; persist only storedFileUUID, readUrl, and small metadata instead.

Failures usually come from adding headers not listed in X-Amz-SignedHeaders, such as Content-Type, which triggers a CORS preflight the bucket rejects. Send a bare PUT with raw bytes and only the signed headers.

Broker the upload on the app feature backend using FBS_FEATURE_TOKEN, which has files.write permission, then return the storedFileUUID and readUrl to the client. Visitor browser tokens typically cannot call file write operations.

Relative stored-file URLs starting with / resolve against the wrong host when placed directly in links or image sources. Prepend https://app.thefusebase.com/box/file to relative URLs before displaying or persisting them.