Upload a sandbox file
Writes one file to the given absolute path inside the sandbox via multipart/form-data, overwriting any existing file.
Authentication, host, and the error envelope are identical to the download endpoint (see GET /files).
Request constraints
- The target path is given only in the
pathquery parameter. Including an additionalpathform field in the body is rejected (400): when the two sources disagree there is no way to know which to trust, and failing is better than guessing. - The request body must be
multipart/form-data; any otherContent-Typereturns415. - One file per request.
- No chunked/resumable upload. There is no
Rangesemantics for uploads; an interrupted upload must be resent in full. A data center may enforce a per-file size limit and return413when exceeded; the limit is not exposed through the API.
Authorizations
Sandbox data-plane token — the sandbox_access_token returned by the create/connect endpoints. Used for /files, Sandbox-Exec, and other data-plane endpoints; the control plane (/api/v2) does not accept it, and conversely the control plane's Authorization: Bearer is invalid on the data plane.
The token is bound to its sandbox: using sandbox A's token against sandbox B's host fails. It stays valid until the sandbox's lifetime ends; there is no separate rotation endpoint (rotate_traffic_token rotates the port traffic token traffic_access_token and does not affect this one).
Query Parameters
Absolute path inside the sandbox. Must start with /; relative segments such as . / .. are rejected. No semantic interpretation is applied beyond existence checks; for writes, the parent directory must already exist.
1Perform the file operation as this user; defaults to the sandbox's default user. Optional capability: some data centers ignore this parameter and always act as the default user, so do not rely on it for permission isolation.
Body
The file content.
Response
Write complete. The array shape exists for compatibility with existing SDKs; it currently always holds a single element.