Yes. Using the Shotstack API as the rendering layer inside your own commercial product is a standard and permitted use.

The typical shape looks like this, and all of it is permitted:

No. Because your customers have no access to Shotstack credentials, APIs or editor interfaces, you are consuming the API as infrastructure inside your own product rather than reselling access to it.

Resale would mean giving your customers Shotstack access, credits or API keys in their own right. Building your product on top of our API is not that.

No. Nothing additional is required before you launch. You only need a plan carrying enough credits for your rendering volume.

Yes. You may white label entirely. No attribution to Shotstack is required anywhere in your product or on your rendered output.

Yes, and we encourage it. You are responsible for the media you submit to us, so you should hold your customers to equivalent restricted-content and rights requirements in your own terms.

Yes to all three. The Studio SDK exists to be embedded in products like yours, and commercial use is its intended purpose.

The SDK is licensed under PolyForm Shield 1.0.0, which grants a Changes and New Works licence for any permitted purpose. That covers restyling the editor so it appears as a native part of your product, and building your own media library, projects, templates, AI-assisted editing, scheduling and other functionality around it.

Your end users do not need their own Shotstack accounts or API keys.

Two, and they are light.

Noncompete. This is the operative boundary. The licence permits any purpose except providing a product that competes with the software, or with a product we provide using the software. It reads broadly: competing through a different interface or platform still counts, and so does a free product. In practice, embedding editing as a component of a broader product sits comfortably outside it. What would cross the line is exposing the editing or rendering layer as a standalone product, or marketing it as a substitute for Shotstack.

Notices. Anyone who receives a copy of any part of the software from you must also receive the licence terms, or the URL for them. In practice that means keeping the licence text or its URL in your bundled third-party notices, as you would for any dependency. Nothing has to appear in your user interface. We do not ship a Required Notice: line with the SDK, so there is no extra notice to reproduce.

There are no attribution, branding or other commercial-use conditions beyond these.

Not as something third parties build on in their own right. The licence does not allow sublicensing or transferring your licence to anyone else.

Your end users using your product is fine. They are using your application rather than receiving a licence to the SDK. Shipping the SDK, modified or otherwise, as a component others can develop against is not.

You and your customers do. Shotstack claims no ownership of source media submitted to us or of the files we render, so those rights remain yours to pass on to your customers.

No. Customer-submitted media is never used to train or fine-tune any Shotstack model.

Clause 2.7 of our Terms permits analysing assets and API call data for product development purposes. In practice that means things like diagnosing a render that failed on an unusual codec, generally while supporting a request, plus aggregate usage analytics. It is not model training.

Note that this is separate from the question of which sub-processors receive your media. Some features route media to a third-party provider in order to work, for example transcription and automatic captions. See the sub-processor question below.

If you would prefer assets were not stored with us automatically, clause 2.9 lets you opt out. At the payload level, adding "destinations": [{ "provider": "shotstack", "exclude": true }] to a render means the output is never hosted on our CDN.

See also How to Delete Hosted Assets or Storage in Shotstack.

Processing is primarily in AWS ap-southeast-2 (Sydney), with CloudFront handling delivery, and some processing in the United States. Region pinning is not available today.

The authoritative and current list is always shotstack.io/sub-processors. At the time of writing it names three:

That page is updated at least seven days before a new sub-processor begins processing Customer Personal Data, and that update constitutes notice under the Data Processing Addendum. Customers may object to a new sub-processor on reasonable data-protection grounds within seven days. Our DPA is at shotstack.io/dpa.

All of them apply at the account level, which suits a central account serving many of your customers.

For a full breakdown see Understanding Shotstack credit consumption.

On a subscription, your videos and images keep rendering. Credits used beyond your allowance are charged as overage at the end of your billing cycle, at a 30% premium to the rate in your plan.

On Pay As You Go there is no overage. The API stops functioning until you purchase more credits.

Yes. Subscription credits roll over up to 3x your monthly allowance for as long as the subscription stays active. They only expire if the subscription becomes inactive or is cancelled.

Our status page is at status.shotstack.io. You can subscribe by email using the Subscribe button, or consume it programmatically at status.shotstack.io/rss.xml. That RSS feed is the platform-level signal, and is distinct from the render callbacks you receive per job.

Incidents are posted while they are being worked on, not only after resolution, and for major issues we email users directly. Planned maintenance is posted the same way, and major maintenance that may cause downtime is also emailed.

One limitation worth planning around. The status page currently monitors the Edit API and the dashboard. A fault confined to a single asset type, where the API itself stays up and keeps accepting requests, will not currently trip it. We are expanding the status page to cover asset-level failures.

To be plain about the commitment: the above is our practice, not a contractual obligation. The only published notification obligation is the personal data breach clause in our DPA, and there is no published target time from detection to customer notice. We run support 24/7 and typically resolve unplanned incidents within around two hours depending on severity.

Schedule 2 is an availability SLA, so a render that is accepted but never reaches done, while the API itself remains available, is not automatically inside it.

Any claim you raise will be investigated and assessed against the terms. In practice, where the severity or the disruption warrants it, we have compensated customers regardless of whether the strict terms were met.

Claims are submitted by email within 10 days of the incident. We are not prescriptive about evidence, so render IDs, timestamps, error responses or logs are all fine. Uptime history is published on the status page.