You cannot use Sora to create a new video today. OpenAI discontinued the Sora web and app experiences on April 26, 2026, and discontinued the Sora API on September 24, 2026. This article is therefore not a current Sora setup tutorial. It explains what Sora demonstrated, how to handle videos created before discontinuation, and what a team should verify before designing a replacement workflow.
If you need an existing Sora video, start with OpenAI’s Sora discontinuation notice and export guidance. If you need a new video, stop a Sora-specific implementation plan and evaluate a currently documented provider instead. Do not assume that an old login guide, API example, automation recipe, or retention promise still applies.
For example, a marketing team with a Sora clip in an old campaign should first retrieve it using the official instructions, preserve the original file, and record its history. A team planning a new campaign should assess provider access, output retrieval, file validation, rights review, and publication controls before automating anything.
Can you use Sora AI today?
No. OpenAI states that its Sora web and app experiences ended on April 26, 2026, and its API ended on September 24, 2026. There is no current Sora generation workflow to configure from the verified information.
Former users should use OpenAI’s discontinuation notice for account-specific export and data-handling information. The notice, rather than an older tutorial, is the appropriate source for current instructions. Do not infer button names, retention periods, API behavior, or continued access from historical documentation.
A discontinued product is not a live automation target: use official guidance for existing assets and documented provider access for new work.
How Sora changed: research preview, product, and Sora 2
Different Sora articles describe different stages. OpenAI’s February 2024 research material, its later product announcement, and its Sora 2 announcement should be read as separate historical sources rather than combined into one feature list.
| Stage | Historical description | How to interpret it | Source |
|---|---|---|---|
| Original research, February 2024 | High-fidelity videos up to one minute, with text, image, and video prompting demonstrations. | Research description, not a current duration limit or access promise. | OpenAI Sora research page |
| Later product announcement | Launch conditions included outputs up to 20 seconds and 1080p. | Historical product claim that differs from the research description. | OpenAI Sora page |
| Sora 2 announcement | Video generation with synchronized dialogue and sound effects. | Later model announcement, not evidence of present availability. | Sora 2 announcement |
| Current status | Web and app experiences and the API have been discontinued. | Use the discontinuation notice for present access and export information. | Discontinuation notice |
OpenAI’s technical report describes Sora as a diffusion transformer operating on spacetime patches representing images and videos. It explains research methods and qualitative capabilities, but it is not a complete implementation guide, API reference, or current access contract.
The one-minute research description and the later 20-second product announcement refer to different Sora stages. Record the model or product stage and publication date beside every historical claim, and never use a research demonstration as evidence of a current feature or API contract.
What Sora could do, and what its demonstrations did not guarantee
OpenAI’s historical materials described prompt-based video generation, image prompting, video extension, filling missing frames, and video-to-video editing. The research page also showed examples involving multiple shots and visual continuity. These were descriptions or demonstrations of earlier systems, not guarantees that every generation would preserve a character, style, object, or camera movement.
The original research materials documented inaccurate physics, inconsistent changes to object states, spatial errors such as confusing left and right, and difficulty following precise event sequences or camera trajectories. Those limitations belong to the documented research context. They should not automatically be generalized to every later version, but they are useful reasons to inspect any retained output rather than trust the prompt alone.
One technical description also needs care. OpenAI’s technical report discussed highly descriptive captions generated through a recaptioning process for visual training data. Describing this simply as “training on alt text” is not precise. The report does not provide a complete implementation or production API specification.
Generation accuracy and misuse risk are separate issues. A model can produce a physically implausible scene, while realistic-looking video can also mislead or impersonate. OpenAI documented historical provenance measures including C2PA metadata and visible watermarks. Those signals may be removed or altered by editing, transcoding, reposting, or screen recording. See OpenAI’s information about creating with Sora safely and the Sora 2 system card for historical safety context.
What former Sora users should do with existing videos
Use the official discontinuation notice for the exact export process and account-specific data guidance. After retrieval, preserve the original file unchanged and create a separate record of its source, retrieval date, available provenance, and later edits. The archive and register can use the organization’s chosen storage or project system. The fields below are a proposed record design, not an OpenAI or ClickUp schema.
One asset record should represent one retained file version. Create a new version record when an edit, crop, caption pass, or transcode produces a different file. A proposed record might look like this:
{
"asset_id": "asset-illustrative-042",
"source": "Sora, if confirmed",
"retrieved_at": "2026-10-30T14:20:00Z",
"original_file_uri": "controlled-archive/video.mp4",
"file_checksum": "calculated-file-checksum",
"provenance_status": "unknown",
"transformation_history": [],
"review_owner": "media-owner"
}The values are illustrative. The checksum identifies this retained file version, while transformation_history records how later versions were produced. Do not use a daily count, prompt text, or project name as the primary identifier for an individual asset.
How to choose and operationalize a replacement
This is a proposed readiness and governance design, not a tested Sora integration. The research for this article did not establish the current availability or suitability of Make-A-Video, Lumiere, or Synthesia. Do not present those names as verified recommendations without separate current official research.
Before selecting a provider, locate current official product or API documentation. It should explain access, model identifiers, generation status, output retrieval, usage limits, retention, restrictions on input media, and export formats. If an important behavior is undocumented, keep that step manual rather than automating an assumption.
- Is current access and the exact model identifier documented by the provider?
- Can the team determine generation status and retrieve the resulting file using documented behavior?
- Are limits, retention, permitted input media, and export format stated?
- Can retries use a client-generated request UUID or equivalent key without creating unintended duplicate assets?
- Can deterministic file checks and a human approval gate happen before publication?
- If any answer is unknown, can the team leave the step manual until verified?
A proposed workflow is: approved brief → documented replacement provider → generation attempt → retrieved file and metadata → deterministic checks → human content and rights review → approved publishing destination. The provider performs generation. A separately approved language model could help convert a brief into a draft prompt, but it should not decide whether the resulting video is suitable to publish.
Keep the data grain explicit. A prompt revision, generation attempt, output asset, review decision, and published video are different records. One prompt revision may produce multiple attempts, and one attempt may produce multiple output files. An asset register should have one row per output file version. A generation-attempt log should have one row per attempt and link to zero or more asset records.
For duplicate protection, the calling system should assign a unique request UUID. Do not deduplicate by prompt text because identical prompts may intentionally create distinct variations. If multiple workers can process requests concurrently, enforce uniqueness with a database constraint or transactional upsert. A lookup followed by a separate insert is not race-safe.
Deterministic validation should check that the file exists, the MIME type is allowed, the checksum is recorded, the duration and resolution meet the brief, and required fields are present. Human review should assess prompt adherence, continuity, likeness, misleading context, rights, and brand suitability. Write to a publishing destination only after checks pass and a reviewer approves that exact asset version.
An illustrative asset record could contain generation_attempt_id, prompt_revision_id, provider, model_version, output_uri, file_checksum, duration_seconds, resolution, provenance_status, rights_review_status, and human_approval_status. The attempt identifier belongs to one generation attempt; the asset identifier belongs to one resulting file version. If retrieval fails, the automation owner investigates the provider’s documented behavior. If rights or context are uncertain, the named reviewer blocks publication.
ClickUp can be used as a general project-tracking layer, but the verified information does not establish a current Sora integration or video-generation workflow. ClickUp setup and automations may be relevant if a team wants to organize a general review process there. Any fields or workflow described in this article are proposed designs, not native ClickUp Sora features.
Frequently asked questions
Can I use Sora today?
No. OpenAI says its web and app experiences ended on April 26, 2026, and its API ended on September 24, 2026.
Can I still export videos I made with Sora?
OpenAI’s discontinuation notice provides current export and data-handling guidance. Follow the instructions that apply to your account and do not assume indefinite access.
Did Sora ever generate one-minute videos?
The original research materials described high-fidelity videos up to one minute. Later product claims used different conditions, including a launch description of up to 20 seconds and 1080p. Neither describes current access.
Could Sora work from images or existing videos?
Historical research materials described image prompting, video extension, missing-frame filling, and video editing demonstrations. These are historical capabilities, not current access instructions.
Was Sora trained on alt text?
That is an imprecise summary. OpenAI’s technical report described highly descriptive captions generated through a recaptioning process for visual training data.
Can I connect Sora to ClickUp, Make, or Zapier now?
Not as a current Sora workflow supported by the verified discontinuation information. A replacement provider and its current official documentation would be required before designing an integration.
Are old Sora videos automatically cleared for publication?
No. Exporting a file does not establish rights, likeness permission, factual accuracy, provenance, or suitability for a particular audience. Review the exact asset and its intended context before publication.