Video

Upload videos

Transfer owned source media directly to storage, then request asynchronous processing through the account protocol.

Select compatible source media

Modal validation	Current behavior
Containers and MIME types	MP4: video/mp4. MOV: video/quicktime. WebM: video/webm. MKV: video/x-matroska.
Size	At most 5 × 1024³ bytes, or 5 GiB. The interface labels this as 5 GB.
Duration	At most 900 seconds. The modal rejects durations greater than 15 minutes.
Metadata	The browser must read video metadata before the selection is accepted.
Language	English or Other. English is selected initially.

These are upload-dialog checks. A supported container does not guarantee that every codec can play or decode in every browser.

A misleading or missing MIME type can fail validation even when the filename has a supported extension. Changing the extension does not convert media.

Upload and processing failures

Understand the direct-storage transfer

The application creates an owned provisional video row.
The browser uploads the video to authorized storage using resumable TUS requests.
The application starts processing after the transfer succeeds.

Transfer setting	Application behavior
Destination	The configured Supabase resumable storage endpoint, not the RapidEye site request body.
Object identity	The newly created owned video ID.
Authentication	The signed-in account’s storage authorization token and storage ownership policy.
Chunk size	6 MiB per chunk.
Parallel uploads	One.
Automatic retry delays	1 second, then 3 seconds, subject to the client’s retry policy and active attempt.

Large media goes directly to storage. Do not send video bytes through an application JSON route or paste a storage service credential into browser code.

Pause, resume and cancel

Action	Effect
Pause	Stops the current transfer without terminating its resumable upload.
Resume	Finds the prior upload and continues the active upload attempt.
Cancel	Terminates the upload and removes its provisional video row.
Transfer failure	Stops the attempt and tries to remove the provisional row.
Cleanup failure	Keeps a cleanup-failed state. Retry cleanup before starting another upload.
Processing-start failure	Keeps the transferred video and offers a retry of processing admission.

Leaving the upload flow aborts its active attempt. Browser-local resume controls do not promise a resumable upload after a page reload or a different device.

Transfer cleanup and processing recovery are different operations. Deleting a provisional row does not establish that an already accepted processing revision was cancelled.

Request ingest after a completed transfer

The account client calls POST https://api.rapideye.ai/v1/parser/upload-video/ with a fresh user bearer token. The source video must already exist under authorized ownership.

Field or header	Type	Meaning
Authorization	Bearer user access token	A verified account principal. The server derives the actor user ID.
Idempotency-Key	Non-empty request identity	Keep the same identity for the same request. The application uses video-upload:<videoId>.
unique_key	String	The owned source video ID. Required.
video_name	String	Source filename or display name supplied to ingest.
video_description	String	Description supplied with the request.
video_ext	String	Source extension, for example .mp4. Processing normalizes its leading dot.
language	String	The selected language, for example english.
idempotency_key	String, optional	Body fallback when the header is absent.
llm_labels_enabled	Boolean, optional	Opt-in processing configuration accepted by ingest. It is not a model or accuracy guarantee.
person_roster	Array, optional compatibility field	The facade validates entries, but current ingest strips this field. Do not rely on a roster affecting analysis.

Account-client ingest request, after authorized source transfer

async function requestIngest({ accessToken, videoId, filename, extension }) {
  const requestId = 'video-upload:' + videoId;
  const response = await fetch('https://api.rapideye.ai/v1/parser/upload-video/', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer ' + accessToken,
      'Content-Type': 'application/json',
      'Idempotency-Key': requestId
    },
    body: JSON.stringify({
      unique_key: videoId,
      video_name: filename,
      video_description: '',
      video_ext: extension,
      language: 'english',
      idempotency_key: requestId
    })
  });
  const payload = await response.json();
  return { status: response.status, payload };
}

This example accepts an existing authorized user token. It does not provision an account, create a video row or transfer source bytes.

Representative 202 response shape

{
  "status": "Successfully Sent Video To Processing: <videoId> <revisionId>",
  "data": { "revision_id": "<revisionId>", "kind": "ingest", "status": "pending" },
  "error": null
}

HTTP 202 means a pending revision was accepted. Retain its revision ID and observe processing separately.

A repeated account admission can return 409 duplicate_request. It does not necessarily repeat the original success response or create another job.

Request identity and usage receipts

Review before publishing

After processing starts, the owner can continue editing. Review thumbnails, detected entities, labels, subtitles, locations and authored metadata before publication.

A processed video and a published embed experience are separate records. Publish an embed revision to change its viewer configuration.

Processing stages and outputs

Configure and publish an embed