Uploads

Send the bytes to storage instead of to us

Two short calls and one transfer that never touches our servers. Use this rather than POST /v1/uploads whenever the client can make two requests: a 2 GB export streamed through the API holds a worker for as long as the connection takes, and sent to the link this returns it costs nothing on our side.

  1. Call this. You get an upload_id, a complete_url, and either a put target or, for a large file, a multipart one.
  2. Send the bytes. A put target is one request with exactly the headers it names. A multipart target is one request per part, each answering with an ETag.
  3. POST to complete_url, reporting the parts if there were any. That answers the same body POST /v1/uploads does.

Add ?ticket=ut_… instead of a credential to use an upload ticket. The complete_url returned then carries the ticket already.

bytes is what decides whether parts are offered. It is a claim about a file we have not seen, so the object is measured again at step 3 and an oversized one is deleted rather than kept.

post/v1/uploads/direct

Request

  • Base URL: https://api.tryplayhead.com
  • URL: https://api.tryplayhead.com/v1/uploads/direct
  • Auth: HTTP bearer

Request body

filenamestring
bytesinteger
content_typestring

Example request

{
  "filename": "cut-v4.mov",
  "bytes": 734003200,
  "content_type": "video/quicktime"
}

Response

Where to put the bytes, and where to say they arrived.

upload_idstring
max_bytesinteger
expires_atstring date-time
complete_urlstring uri

Example response

{
  "upload_id": "upl_9f2a1c"
}

Changes

No recorded changes to this operation across all 1 revision of this API.