Search Documentation
Search across all documentation pages
Source Lifecycle

Source Lifecycle

Storage lifecycle rules automatically delete the original uploaded source file of a hosted video some days after it becomes ready. This reclaims storage for customers who only need the delivered renditions, not the master they uploaded.

Scope — read this first

The rule is deliberately narrow:

  • It deletes only the original source object — the exact file you uploaded.
  • It never touches renditions, manifests, posters, or playback. A video keeps playing exactly as before after its source is deleted.
  • It applies only to hosted videos whose source lives in Transcodely-managed storage (source = upload). Videos ingested into your own storage origins are never touched.
  • It runs per app and can be overridden per video with a pin.

Enabling the rule

Set delete_source_after_days on the app’s hosting configuration. 0 (or absent) disables the rule; a value between 1 and 3650 deletes each hosted video’s source that many days after it becomes ready.

In the dashboard, open the app, go to Hosting Settings, and turn on Delete Original Source. Via the API, merge the field into the hosting config:

curl -X POST https://api.transcodely.com/transcodely.v1.AppService/UpdateHostingConfig 
  -H "Authorization: Bearer {{API_KEY}}" 
  -H "X-Organization-ID: {{ORG_ID}}" 
  -H "Content-Type: application/json" 
  -d '{
    "id": "app_k1l2m3n4o5",
    "hosting_config": {
      "delete_source_after_days": 30
    }
  }'

Changing the value (setting it, clearing it, or picking a different number of days) immediately clears any pending deletion schedules for the app; the rule re-evaluates cleanly under the new setting, always with a fresh warning first.


The timeline

setting enabled (N days)          ready_at + N days
        │                                 │
        ▼                                 ▼
  video ready ──── … ────► scheduled + warned ──── ≥ 72 hours ────► source deleted
                           (video.source_scheduled_                 (source_deleted_at set)
                            for_deletion webhook)

A source is never deleted without a prior warning. At least 72 hours before a deletion, Transcodely:

  1. Sets source_scheduled_for_deletion_at on the video, and
  2. Sends a video.source_scheduled_for_deletion webhook whose payload is a standard video snapshot.

Use that lead time to pin any video you still need in its original form. When the scheduled time passes, the source object is removed and source_deleted_at is set.


Pinning a video

Pinning exempts a single video from the rule. Set source_pinned on the video — pinning also immediately clears any pending deletion schedule:

curl -X POST https://api.transcodely.com/transcodely.v1.VideoService/Update 
  -H "Authorization: Bearer {{API_KEY}}" 
  -H "X-Organization-ID: {{ORG_ID}}" 
  -H "Content-Type: application/json" 
  -d '{
    "id": "vid_a1b2c3d4e5f6g7",
    "source_pinned": true
  }'

In the dashboard, open the video and toggle Keep original source (the scheduled-for-deletion warning also offers a one-click pin). A pinned video never loses its source. Pinning is always allowed — even after a source has already been deleted, where it is a harmless no-op.

Unpinning does not reschedule immediately; the rule re-evaluates later and, if the video is again eligible, sends a fresh warning before any deletion.


Video lifecycle fields

Three read model fields on the Video object describe source state. All concern only the original source; none affect playback.

FieldMeaning
source_pinnedWhether the source is exempt from the rule. Writable via VideoService/Update.
source_scheduled_for_deletion_atWhen the source is scheduled to be deleted. Present only while a deletion is pending; cleared on pin, on setting change, and on delete. Read-only.
source_deleted_atWhen the source was deleted. Set exactly once. The authoritative “source is gone” signal. Read-only.

Re-processing consequence

This is the tradeoff to understand before enabling the rule.

Once source_deleted_at is set, the original master is gone. Any future re-processing that would normally read the source — generating new codecs or renditions, or retro-captioning an existing video — falls back to the best available rendition (the highest-bitrate variant) instead of the original. Quality is bounded by that rendition, not by the master you uploaded.

If you intend to re-encode a video later, pin it so its source is retained. The 72-hour warning webhook exists precisely so you can pin anything you still need before it is deleted.


What is never affected

  • Playback — renditions, manifests, and posters are untouched; delivery is unchanged.
  • Your own origins — videos backed by your storage origins are out of scope; only Transcodely-managed source uploads are ever deleted.
  • Pinned videos — a pinned video keeps its source indefinitely.

  • Webhooks — the video.source_scheduled_for_deletion event and signature verification.
  • Apps — the hosting_config object and UpdateHostingConfig.
  • Videos — the source_pinned field and the video read model.