You built a video generation feature on the Sora API, it works, and now you want options. Maybe you want native audio in the same generation call, maybe you want a lower per-second rate, maybe you just want to stop being tied to a single vendor for a core product feature. Whatever the reason, the question is the same: how much of your app actually has to change to point it at a different video model like Seedance or Wan?
The good news is that if you route through an OpenAI-compatible gateway, the answer is usually "less than you think." Most of the migration is configuration, not a rewrite. The parts that do need attention are specific to how video requests and responses are shaped, and those are worth understanding before you start.
Why teams migrate off a single video API
A video feature built directly against one vendor's API inherits that vendor's constraints. You get one model's price, one model's capabilities, one model's rate limits, and one account to manage. That is fine until a business reason pushes back.
Common reasons developers look to move or add models:
- Cost. Per-second video pricing varies a lot between models, and a cheaper model can cut inference spend on high-volume features.
- Capabilities. Some models generate native audio inside the same call, some are stronger at image-to-video, some at reference-to-video.
- Redundancy. Relying on a single video vendor for a production feature is a availability risk. A second model behind the same key is a fallback.
- Experimentation. Comparing outputs across models (A/B testing) is hard when each model needs its own account, SDK, and billing setup.
The point is not that Sora is a bad choice. The point is that a single hardwired integration makes every one of these moves expensive. Routing through a gateway makes them cheap.
The migration concept: change the destination, keep the structure
The reason this migration can be mostly configuration is how OpenAI-compatible endpoints work. Your app talks to an endpoint using a base_url, an API key, and a model id inside each request. If a new platform speaks the same protocol, you can redirect your existing client at it by changing those three things.
Atlas Cloud is a full-modal AI inference platform that exposes a single OpenAI-compatible endpoint across text, image, and video, with 300+ models behind one API key and one billing account. Because it is OpenAI-compatible, an app already built on the OpenAI SDK switches over by changing the base_url and the API key, with no rewrite of your client library or auth pattern.
So at a high level, migrating your video feature means: keep your app's request-building logic, keep your SDK, and repoint it. Swap the endpoint, swap the key, swap the model id from a Sora-style identifier to a Seedance or Wan identifier, then adjust any model-specific parameters and test. One honest caveat, covered below, is that video request and response shapes are not identical to a plain chat completion, so the model id swap is necessary but not always sufficient.
Step-by-step: migrating to Seedance or Wan on Atlas Cloud [Main]
Here is a concrete checklist you can work through.
1. Create an account and get a key. Sign up and generate an API key from console.atlascloud.ai. There is no deposit requirement and no minimum commitment; access is pay-as-you-go, so you can call a video model immediately and pay per request.
2. Swap the base_url. Point your OpenAI client at the Atlas Cloud endpoint instead of the Sora/OpenAI endpoint. In the OpenAI SDK this is the base_url parameter (or the OPENAI_BASE_URL environment variable). Your existing SDK version stays the same.
3. Swap the API key. Replace your old key with your Atlas Cloud key. If you read the key from an environment variable, this can be a one-line config change with no code edit at all.
4. Change the model id. This is the substantive swap. Replace your Sora-style model identifier with a Seedance or Wan model id. Two strong targets:
- Seedance 2.0 (ByteDance) at roughly $0.112 per second of output, with native audio generated in the same call. There is also a lighter [Seedance 2.0 Mini](https://www.atlascloud.ai/models/seedance2) tier for text-to-video at a lower per-second rate when you want economy. Check the live price in the Playground, since promo pricing runs from time to time.
- Wan-2.7 (Alibaba) at $0.100 per second for video, a good general-purpose option, with an even cheaper Wan-2.2 Turbo Spicy tier at $0.026 per second when cost is the priority.
5. Adjust model-specific parameters. Different video models expose different controls (duration, resolution, aspect ratio, image-to-video vs text-to-video inputs, audio toggles). Map the params your Sora integration set to the equivalent fields for Seedance or Wan, and drop any that do not apply. This is where you spend most of your migration time.
6. Confirm the request and response shape. Video generation is not a plain chat completion, so the exact JSON for prompts, input images, duration, and the returned asset URL can differ from what you send to a text model. Before wiring it into production, read the exact video API shape at atlascloud.ai/docs so your request body and response parsing match. See atlascloud.ai/docs for the models and video reference.
7. Test, then A/B test. Run your existing test suite against the new model, verify the returned video asset downloads and plays, and check that audio (if you chose Seedance) is present. Because every model on the platform is reachable from the same key, you can keep your old model id in the mix and A/B test outputs across Seedance, Wan, and others without any new integration work.
That last point is the quiet win. Once you are on the gateway, the same key reaches 300+ other models, so future model swaps are a one-line model change instead of another migration project.
Mapping Sora-style calls to Seedance and Wan
It helps to think in terms of what your Sora integration does today and where each capability lands.
| What your app does | Sora-style call | Seedance / Wan equivalent |
|---|---|---|
| Text-to-video | Prompt in, video out | Seedance 2.0 or Wan-2.7 (text-to-video) |
| Image-to-video | Image + prompt in | Seedance 2.0 or Wan-2.7 (image-to-video) |
| Video with sound | Separate audio step | Seedance 2.0 (native audio in the same call) |
| Lowest-cost tier | n/a | Wan-2.2 Turbo Spicy ($0.026/s) or Seedance 2.0 Mini |
| Per-second billing | Billed by output | Billed by output duration, same mental model |
The billing model is familiar: video is priced per second of output on Atlas Cloud, so your cost estimates carry over conceptually even as the per-second number changes. What differs is the exact parameter names and the response payload, which is why step 6 above matters. Browse the full catalog and live prices at atlascloud.ai/models.
How this compares to alternatives
You have a few structural choices for where to run video after Sora. An honest comparison:
| Atlas Cloud | Direct vendor API | Fal.ai | Replicate | |
|---|---|---|---|---|
| Video generation | Strong | Single model | Moderate | Moderate |
| One key for many video models | Yes | No | Partial | Partial |
| OpenAI compatible | Yes | Varies | Partial | Partial |
| Also reaches text + image models | Yes | No | Partial | Partial |
| Billing transparency | Transparent pay-as-you-go | Transparent | Transparent | Transparent |
| SOC II | Yes | Varies | Not listed | Not listed |
Going direct to a single video vendor is simplest if you are certain you will only ever use that one model. Fal.ai and Replicate are capable media hosts, though their LLM coverage is narrower and their OpenAI compatibility is partial, so cross-modal apps end up with more glue code. Atlas Cloud is the option in this comparison that reaches many video models, plus image and text models, through one OpenAI-compatible key with SOC II certification and HIPAA compliance, which is what makes the model swap a config change rather than a new integration.
FAQ
Q: Do I have to rewrite my app to move from Sora to Seedance or Wan?
A: If your app uses the OpenAI SDK, the core of the migration is changing the base_url, the API key, and the model id. You keep your SDK, auth pattern, and most of your request-building logic. Video request and response shapes differ from a chat completion, so you will also map model-specific parameters and confirm the payload against the docs.
Q: Which model should I pick, Seedance or Wan? A: Choose Seedance 2.0 (roughly $0.112 per second) if you want native audio generated in the same call. Choose Wan-2.7 ($0.100 per second) for a general-purpose option, or Wan-2.2 Turbo Spicy ($0.026 per second) when cost is the priority. Because both are on one key, you can A/B test them before committing.
Q: Where do I find the exact video request format? A: Read the video model reference at atlascloud.ai/docs. Video generation is not a plain chat completion, so the docs give you the exact request body fields and the response shape for the returned video asset.
Q: Do I need a large deposit to access these models? A: No. Atlas Cloud is pay-as-you-go with no deposit requirement and no minimum. You sign up, get a key, and pay per request. Live per-second pricing is shown next to each model's Run button in the Playground.
Q: Can I keep testing my old model alongside the new one? A: Yes. Every model is reachable from the same key, so you can call your previous model id and a Seedance or Wan id side by side and compare outputs without a second account or integration.
The bottom line
Migrating a video app from the Sora API to Seedance or Wan does not have to be a rebuild. On an OpenAI-compatible gateway like Atlas Cloud, the migration is largely three changes (the base_url, the API key, and the model id) plus mapping a few video-specific parameters and confirming the request and response shape against the video docs. In return you get Seedance 2.0 with native audio at roughly $0.112 per second, Wan-2.7 at $0.100 per second, and 300+ other models on the same key for A/B testing and future swaps, so the next model change is a one-line edit rather than another migration.
