Upload tokens — why your API key stays server-side

Your ek_ API key is your tenant. Anyone holding it can read every video, change your config, and rotate your webhooks. It must never be embedded in a mobile app or web bundle — extracting secrets from shipped clients is trivial.

But uploads should go device → Energixer directly: proxying a 200 MB file through your backend doubles your egress, adds your server to the failure path, and breaks resumability at your hop.

The upload token resolves this tension:

1. Your backend calls POST /v1/videos (with the API key, server-side).
2. The response includes an upload_token — a short-lived JWT that is a capability for exactly one video: claims {type: "upload", video_id, domain_id}, expiring after 2 hours.
3. The device performs the tus protocol with Authorization: Bearer <upload_token>.

Properties worth knowing:

• Single-purpose. The token drives tus for its one video and nothing else. Every JSON API route rejects it (401); it cannot read state, list videos, or touch any other upload.
• Self-revoking. The moment the video leaves pending_upload (finished, cancelled, expired), the token is useless — no revocation list needed.
• Not user auth. Energixer has no user accounts. If you need per-user limits, pass an opaque uploader_ref at initiate; it drives the pending-slot cap and abuse throttles without Energixer learning who your users are.
• Expiry mid-upload (rare; the default window is 2 h): initiate again from your backend and re-upload. Tokens are not refreshed.

Rule of thumb: the API key lives where your database credentials live. The upload token lives wherever the file lives.