跳到主要内容

uploadFileToMy

FileArrayWrapper uploadFileToMy(createNewIfExist, storeOriginalFile, keepConvertStatus, file)

POST /api/2.0/files/@my/upload

Upload a file to My documents

Uploads one file into the caller's own My documents section and returns it inside a single-element array; one request stores exactly one file. The destination takes no identifier: it is resolved from the calling account and created on first use, while a guest account has none and is answered as missing (404). The body has to be multipart/form-data carrying the file part; a request without it is rejected as invalid, and the stored name comes from that part, since unlike POST api/2.0/files/@my/insert there is no separate title. The call is not idempotent: by default a file of the same title is overwritten as a new version, while createNewIfExist=true stores a separate copy under a title made unique with a numeric suffix. storeOriginalFile is not a per-request switch: it writes the same account setting as PUT api/2.0/files/storeoriginal, which decides what happens to the formats listed in extsMustConvert of GET api/2.0/files/settings when they are converted after the response - false replaces the uploaded file with the converted one, true keeps both; keepConvertStatus=true keeps that conversion result readable through GET api/2.0/files/file/{fileId}/checkconversion. Files over the single-request size limit or the account's storage quota are refused; send those through POST api/2.0/files/{folderId}/upload/create_session.

Parameters​

NameInTypeDescriptionNotes
createNewIfExistqueryBooleanSettles the clash with a file already carrying that title: left out, the content is written as the next version of that file; set to true, both survive and the new one gets a numeric suffix in its title.[optional] [example: true]
storeOriginalFilequeryBooleanReaches further than this request: it writes a setting on the calling account, the same one PUT api/2.0/files/storeoriginal writes, and it stays in force for later uploads. True keeps both the uploaded file and the copy the portal converts it into, false replaces the uploaded file with the converted one, and leaving it out keeps whatever the account already has.[optional] [example: true]
keepConvertStatusqueryBooleanDecides whether the outcome of the background conversion outlives the conversion itself. True keeps the queue record, so GET api/2.0/files/file/{fileId}/checkconversion can still report the result or the error; left out, the record is cleared the moment the conversion ends and that call finds nothing.[optional] [example: true]
fileformFile (binary)The content to store, sent as a multipart/form-data part; the name of that part becomes the title of the stored file, with characters a title cannot hold replaced and the name cut to 170 characters. A request without it is rejected as invalid.[optional]

Responses​

Status codeDescriptionTypeResponse headers
200An array holding the single uploaded fileFileArrayWrapperX-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset
400The request has no file part--
402The file exceeds the single-request upload limit, or storing it would exceed a storage quota or size limit--
403Uploading a file to the personal section is not allowed for this account--
404The caller has no personal section, so there is nothing to store the file in--
415The installation restricts uploadable formats and the file extension is not among them--
401UnauthorizedErrorApiResponse-
429Too Many Requests.ErrorApiResponseRetry-After
500Internal Server Error.ErrorApiResponse-
502Bad Gateway. Returned by the reverse proxy, response body may be HTML and not JSON.--
503Service Unavailable. Returned by the reverse proxy, response body may be HTML and not JSON.--

Return type​

FileArrayWrapper

Authorization​

Basic, OAuth2 (scopes: read, write), ApiKeyBearer, asc_auth_key, Bearer, OpenId

HTTP request headers​

  • Content-Type: multipart/form-data
  • Accept: application/json