Attach an uploaded file to a work item
POSThttps://
Step 3 of 3.
Access
- Token scope
- api:
write: project_management Without it:
403 insufficient-token-scope. - Permission
- project_management::
manage_work_items Without it:
403 insufficient-permission. - Rate cost
- 1 unit, write bucket. A write costs the same whatever
viewyou ask for. - Also
- Needs
Idempotency-Key. Never cached:private, no-store. Unknown body keys are refused, never dropped.
Both are checked, scope first. A token never does more than its user. How access is checked
Turns bytes you have already uploaded into an attachment on the work item named in the path, and returns the file in the detail view. upload_id is the only key this accepts: create a ticket with POST work-items/{work_item}/uploads, PUT the raw bytes to its upload_url, then send its id here. Everything about the file (its name, its size, its media type, its collection and its storage location) is read off the ticket and off the bytes that actually arrived, so file_name, mime_type, byte_size, collection and disk are all a 422. The ticket must have been created for this work item, by this API token, and must not have expired or been registered already; each of those is a specific 409 or 422 naming the cause. The server re-hashes the stored bytes and compares them with what it received before creating anything. This works exactly like an upload in plnnrly, so thumbnails and notifications follow identically. Attaching requires project_management::manage_work_items, the same permission plnnrly checks. Idempotency-Key is required: a lost 201 retried without one would report a failure for a create that succeeded. There is no Location header (a file has no item URL of its own), and no PATCH or DELETE on a file; remove one in plnnrly.
Path parameters
Query parameters
Unknown parameters are refused with 400, naming the parameter.
Request headers
A correlation id of your own. It is recorded in our logs next to the server's request id but never returned: the response header always carries the server's id. A value that does not match the pattern is discarded silently, never rejected.
Request body
Unknown keys are refused with 422, naming the key.
The id of the upload ticket whose bytes become this file. Create one with POST work-items/{work_item}/uploads or POST drive-items/{drive_item}/uploads, PUT the bytes to its upload_url, then send its id here. Write-only: it is never rendered on a media row, and it is the only key either attachment store accepts.
Response 201
Returns a Media in the detail view.
Headers
ETag- A strong validator of exactly this representation.
Idempotency-Replayedtruewhen this response was replayed from a storedIdempotency-Keyrather than produced by a new write.RateLimit- The IETF
httpapi-ratelimit-headersform of your remaining allowance on the tightest bucket this request touched. RateLimit-Policy- The ceiling and window of that bucket, as
<limit>;w=<seconds>. X-Request-Id- The server-generated ULID correlating this response with our logs.
Every response also carries Cache-Control, Vary, X-Content-Type-Options, X-Plnnrly-Api-Version, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Headers and versioning
Signed download URL, requiring your bearer token. Request with ?include=url. Null only where your organisation's file storage cannot sign URLs, in which case the response carries a signed_url_unavailable warning and downloads are not available through the API.
Errors
415 Unsupported media type.
422 Unprocessable content.
7 errors every operation can return: 400, 401, 404, 406, 429, 500, 503
400 Bad request.
idempotency-key-requiredinvalid-cursorinvalid-query-parametermalformed-requestunsupported-parameter
401 Unauthenticated.
404 Not found.
406 Not acceptable.
429 Too many requests.
500 Server error.
503 Service unavailable.
This path allows GET, POST. Anything else answers 405.
Something wrong or missing on this page? Tell us