Method notes

What each method actually does, including the fields it takes, what it returns, and the cases it declines. Read alongside the Apex quick reference.

uploadFiles

Server-side base64 upload for small files. Request: recordId, fileName (with extension), contentType, bodyBase64 (raw base64, no data: prefix). Result: file (FileInfo), downloadUrl. Images uploaded this way skip the thumbnail pipeline - use the presigned pair for images.

requestUploadUrls / confirmUploads

Large-file path for external providers. requestUploadUrls returns uploadUrl, uploadKey, expiresAt, requiredHeaders (include on the PUT), requiresContentRange (SharePoint). The client PUTs bytes directly to storage, then confirmUploads creates the file record and enqueues image pipeline processing. Fails with ERROR_UNSUPPORTED_PROVIDER on Salesforce storage.

relocateFiles / getRelocationStatus

Moves an existing Salesforce file (069… ContentDocumentId) into the org’s active external provider, server-side and asynchronously via multipart upload. No practical size ceiling; the accept call is callout-free, so it runs after DML and inside Batchable/Queueable.

Request: fileId (source 069…, required), recordId (required), deleteSourceAfterRelocate (optional, default false - keep the Salesforce source; true deletes it after the copy lands).

The synchronous result is an acceptance, not an upload-complete signal: on accept, success = true, status = 'Uploading', and fileId is the relocated file’s durable opaque handle. Store it once; it is the file’s permanent id and resolves to the external file once complete (and back to the retained source if the relocation fails).

getRelocationStatus is a callout-free poll by handle, returning status ('Uploading'/'Complete'/'Failed'), fileId (when Complete), and relocationErrorMessage (when Failed). It is the required completion channel for soft-dependent packages (which cannot subscribe to the Storage_Event__e platform event). Subscribers that can reference Sliick types may instead listen on Storage_Event__e.

Requires an external provider that supports server-side multipart upload and the large-file-streaming entitlement; otherwise items fail with ERROR_UNSUPPORTED_PROVIDER or ERROR_STREAMING_NOT_ENABLED.

Callers that want to know readiness ahead of time - rather than finding out from a declined relocateFiles call - can use getStorageReadiness (see Check relocation readiness), which reports provider connectivity, multipart support, and the streaming entitlement as one combined relocateReady flag.

One-time org prerequisite: an admin clicks Set up large-file streaming in the Storage Settings panel once, which writes the Remote Site Settings the async stream requires. A headless caller cannot provision these.

listFiles

Files attached to each record - the active provider’s files only, createdDate DESC, max 200 per record. The default returns just the files stored in the org’s currently-active storage provider (the one Storage Settings selects / new uploads route to); files left behind in a now-inactive provider (e.g. a legacy Sliick_Cloud image after the org switched to SharePoint) are excluded. The provider filter is applied before the 200 cap, so the cap counts only the files actually returned.

Set includeAllProviders = true on the request to restore the legacy merged-across-all-providers behaviour (every provider’s files). This is an additive, non-breaking opt-out, shipped at getCapabilities revision 2 - soft-dependency callers can feature-detect it via the revision before relying on the active-provider default.

No download URLs (resolve per file with getDownloadUrls). FileInfo fields: fileId, name (no extension), extension, contentType, sizeBytes, provider ('Salesforce', 'Sliick_Cloud', 'S3_Compatible', 'GCP', 'Azure', 'SharePoint'), processingStatus ('Pending'/'Complete'/'Failed', null for Salesforce files), isCurrentVersion, tags (read-only in v1), createdDate.

getDownloadUrls / getFileBodies

getDownloadUrls returns a short-lived download URL per fileId, plus name, contentType, sizeBytes. External URLs are presigned and expire within minutes; expiresAt may be null when the provider does not report it.

getFileBodies returns raw base64 bytes (no data: prefix) plus contentType and fileName. Heap-bound (~4MB per file) - request large files individually, or use getDownloadUrls and fetch outside Apex.

There is no server-side ZIP. To bundle multiple files, fetch a getDownloadUrls manifest and assemble the ZIP in the browser (JSZip, or a streaming library like client-zip); bytes go browser ↔ provider directly. The bucket must allow cross-origin GET from the Lightning/Experience origin.

deleteFiles

Removes the file from the given record (fileId + recordId both required). Unified across providers: the file is detached from this record; when that was its last attachment the file itself is deleted (Salesforce files immediately, external files via the orphan-cleanup grace period). Deleting a file that is not attached is a successful no-op.

Deletes are strict. A last-attachment delete removes the bytes from external storage first - SharePoint into its site recycle bin, S3/GCS/Azure via an object DELETE that lands in native soft-delete or versioning where the bucket has it enabled, Sliick Cloud permanently - and only then removes the link. When the byte-delete fails, that item returns ERROR_EXTERNAL_DELETE_FAILED and nothing changes in Salesforce. The same code comes back for a file whose provider is not the active provider (“Connect {provider} to delete this file”) and when the transaction’s callout budget runs out mid-bulk (“Delete fewer files per call and retry”).

The deleted file stays restorable from the admin Deleted Files tab for 100 days, subject to the provider’s own retention.

renameFiles / moveFiles

renameFiles updates the display name only (metadata; any extension in newName is stripped; storage paths unchanged).

moveFiles moves the file’s attachment from sourceRecordId to targetRecordId; requires edit access on both records. If the file is already on the target, the move just removes it from the source.

On SharePoint the physical file moves too, into the target record’s folder via a server-side Graph move. The item id is stable and native versions travel with it; on a destination name collision the file lands under a keep-both name, for example invoice (1).pdf. Two consequences for callers: the file’s SharePoint path, and possibly its name, changes; and the operation performs callouts, so it can no longer run after DML in the same transaction - move first, or go async. It is idempotent per item, so a retry of a partially failed move converges.

Every other provider, and files belonging to a previously connected provider, keep the repoint-only semantics: no bytes move and no callouts.