Where Background Removal APIs Send Your Users' Video

Picking a background removal API is an engineering decision right up until it stops being one. The masks hold on hair and glasses, the latency fits, the integration is a two day job, and then a security reviewer at your own company or at your largest customer sends over a questionnaire asking where the frames go and who keeps them afterwards. The API reference does not cover any of that.

TL;DR

• Remove.bg puts no duration on how long the images sent to it are kept, and it caps server logs at three months.
• Photoroom's model training clause covers photos people send to its app, and the same text excludes API images.
• VideoBGRemover publishes a full erasure sequence: live while the job is active, gone on a verified request, production erasure inside 30 days, backups seven days beyond.
• Files on the fal CDN are readable by anyone holding the link unless you attach an access control list, and inputs inherit the account default rather than the header on the inference call.
• Banuba's Face AR SDK is licensed by a token in .txt format with a published expiry ladder, and the same page never says whether the SDK phones home to check it.
• One of the five is sales gated. The other four hand you a key at sign-up.

Everything here was read off vendor pages on 8 September 2026

I ran no tests for this one and there is not a millisecond anywhere below. Every claim comes from a vendor's own live pages as they stood on 8 September 2026, linked next to the sentence it supports. Those pages get edited, often quietly, and any figure that decides a build should come from the vendor in writing, addressed to you.

Does the video frame leave the device?

Four of the five are hosted services, so the media crosses the network before anything happens to it. Remove.bg's privacy policy, last updated 16 July 2025, set out the sequence plainly when I read it on 8 September 2026: images go up securely, get processed, and are provided for download. Photoroom, VideoBGRemover and Veed running on fal.ai work the same way.

Banuba's Face AR SDK is the one product here that is not a hosted service, since the processing happens inside your app rather than on a server you call. That settles the media path and leaves the license path open, which is where its published material stops short.
For the hosted four, the honest questionnaire entry is yes. Everything else is argued after that.

What does each vendor keep, and for how long?

	Banuba Face AR SDK	Remove.bg	Photoroom	VideoBGRemover	Veed on fal.ai
Where processing happens	On the device, inside your app	Vendor servers	Vendor servers	Vendor servers	fal's platform
Does user media leave the device	No	Yes	Yes	Yes	Yes
What is being compared	On-device SDK, licensed by a token in the client app	Hosted REST image service	Hosted REST service plus a consumer app	Hosted video service	A model run on fal's platform
Access	Sales gated: demo and commercial tokens are both issued by a person	Open self-serve with an API key	Open self-serve, custom enterprise pricing	Open self-serve, enterprise DPA available	Open self-serve
How long the vendor holds media	No media reaches a vendor server	"Delete them shortly after", no duration given	Not stated	Live while the account or job is active, erased on job deletion or a verified request	No CDN expiry stated
Tail after deletion, and logs	No media reaches a vendor server. Server logs not applicable	Server logs kept at most three months	Not stated	Production erasure inside 30 days, soft-delete systems and rolling backups seven days beyond	Inputs and outputs kept 30 days by default
Training use	No media reaches a vendor server	Not stated	Training row covers app photos, API images carved out	Does not train or improve models on customer content	Not stated
Named third-party audit	Not named	Not named	SOC 2 Type 2	Not named	Not named
Contract instrument named	Not named, terms go through an account manager	EU and UK representative named (EDPO), rights listed	Not named	DPA incorporating the 2021 Standard Contractual Clauses	Not named
Control you can set yourself	Keep the token on your own server rather than in the app bundle	Not offered	Not offered	Job deletion and verified erasure requests	X-Fal-Store-IO: 0 on the request, ACL on the upload
Still open on their own pages	Whether the SDK makes a network call to validate the token	How long processed images are actually kept	Retention duration for API media	No named outside audit	CDN file expiry, and what happens to assets at account end

Every cell above is what that vendor's own published pages said when I checked them on 8 September 2026, and an empty-looking cell means I found nothing on the subject, not that the vendor does the opposite. None of it is a measurement.

The first row exists so the first column does not get scanned as like-for-like. An on-device SDK and a hosted video service fail a questionnaire in completely different places, and putting them side by side is only useful if you keep that in view.

Access splits four to one. Remove.bg, Photoroom, VideoBGRemover and fal all issue a working key at sign-up. Banuba is the gated one: a demo credential comes from a sales manager or the website request form, and a commercial credential comes from an account manager after payment. Sales gating is not automatically a problem, but it does mean your evaluation timeline includes somebody else's calendar.

The most specific writing about retention here belongs to VideoBGRemover. Its privacy page says uploaded videos, masks, previews and outputs stay available while the account or job is active and are erased when you delete the job or send a verified request, that production erasure completes within 30 days, and that soft-delete systems and rolling backups may hold copies for seven days beyond that. No other page here puts a tail on the number. Remove.bg's three month ceiling on server logs and the 30 day payload default in fal's media expiration docs are real figures too, though both of those describe logs and JSON rather than the media itself.

On model training, Photoroom and VideoBGRemover arrive at similar comfort from opposite directions. Photoroom carves API traffic out of model improvement in its own legal text. VideoBGRemover rules out training on customer content across the whole service.

Photoroom is the only one of the five naming an outside auditor: its API page states SOC 2 Type 2. If your reviewer's checklist has a certification line on it, that is currently a one horse race here.

For a contract instrument, VideoBGRemover names an enterprise DPA incorporating the European Commission's 2021 Standard Contractual Clauses, and Remove.bg names EDPO as its EU and UK representative alongside the usual list of data-subject rights. The other three leave that conversation to sales.

fal is alone in handing you controls you operate yourself. Everyone else describes their own conduct and asks you to accept the description, which is a weaker artifact to walk into a review with, however honest the description turns out to be.

Can anyone else open the file the API handed back?

On fal, the default is yes. fal's file access control docs state that every object on the fal CDN carries an access control list, and that by default CDN URLs are reachable by anyone who has the link. A long random URL does not make an object private, and links leak through logs, support tickets and screenshots.

Inputs are a separate case on the same page. The SDKs push them to the CDN before the inference call runs, so they are not governed by the ACL header you set on that call and instead inherit the account default. To constrain an input you set the ACL on the upload itself.

To size your own exposure, with named inputs you can redo on paper:

1. Start with clips per user per day. Mine here is one, and it is yours to substitute.
2. Multiply by daily active users who touch the feature. I am using 500, an illustrative figure to replace with your own.
3. 500 x 1 = 500 input objects landing on the CDN each day.
4. CDN URLs are public by default, so unless an ACL is attached at upload time, those are 500 publicly reachable URLs added per day.
5. The JSON payloads default to 30 days, so 500 x 30 = 15,000 request records held in the history at any steady state moment.

In elapsed terms, that history never empties while the feature is switched on, because the oldest record ages out 30 days after it was created and a fresh one arrives the same day.

Are my users' images used to train the vendor's models?

Photoroom's privacy policy carries a retention table with a row titled "Training our AI model", covering photos and images that people sent to Photoroom, on a legitimate interest basis, held for as long as training requires. The same document then states that this model improvement does not apply to images processed through the API. That clause is about app users, not API traffic, and getting the distinction backwards in a questionnaire will cost you a week of email.

VideoBGRemover takes the other route and states flatly that it does not use content people send it, or content it generates, to train or improve machine learning models. That single sentence covers the whole service.

Remove.bg's policy, fal's legal pages and the Banuba licensing page say nothing either way, going by what was up on 8 September 2026. That absence does not amount to a denial, and it stays open until the vendor answers in email.

Who else on my team can see the requests?

fal's privacy policy is unusually direct about this. If you are a member of a Team Account, it says, other members of that Team Account may view billing information, API keys, and AI model requests, including any input and output data.

Think that through before you invite the contractor. Whoever sits in the account can read the media your users sent, and your key too.

The other four say nothing about who inside a customer account can read request bodies, in anything they published as of 8 September 2026. If the question comes up, and it always has for me, you will be relaying an email rather than pointing at a URL.

What happens to the feature when the license lapses?

Banuba is the only one of the five that publishes what happens after the license runs out. Its token management documentation describes the token as an automatically generated set of characters in .txt format, unique to each client, that activates the licensed SDK functionality in the client app.

The expiry ladder on that page has three rungs. A credential that has not expired means the SDK works as expected. One expired by a month or less still works, with a watermark displayed. Past a month, the functionality will not work.

The same page recommends keeping the credential on your own server instead of in the app bundle, and the reasoning is operational: ship it inside the binary and every renewal means a new build queued for App Store or Play Store approval.

What the page does not state is whether the SDK contacts Banuba at runtime to validate the credential. The expiry ladder is written down. Whether a network call sits behind it is left open, so a reviewer asking about outbound traffic needs that confirmed by the vendor.

Among the hosted four, only VideoBGRemover ties asset availability to account state in its published terms, saying that videos, masks, previews and outputs stay available while the account or job is active. For Remove.bg, Photoroom and fal, I found nothing published about what becomes of stored assets once an account ends.

What will the vendor put in writing?

Photoroom offers an attestation from an outside auditor plus an explicit carve-out for API traffic. VideoBGRemover offers a DPA built on the 2021 Standard Contractual Clauses for enterprise customers under GDPR. Remove.bg names a representative for EU and UK data subjects and enumerates the rights those people hold. fal offers something different in kind, two controls you operate yourself: the store header on the request and the ACL on the upload. Banuba issues its commercial license through an account manager after payment, so the terms conversation happens with a person and whatever you need has to end up in that thread.

Two of the five publish noticeably less than the rest. Remove.bg gives no duration whatsoever for the images sent to it, only that they go "shortly after", and shortly is not a number your reviewer can log. Banuba's material covers the license credential thoroughly and stops before the SDK's runtime network behavior, which leaves the most basic question about an on-device product unresolved on the public web.

Ask for the four answers in writing before you sign

Four items close most of the gaps above, and they fit in one email.

1. A number, in days, for how long processed media is held, and a second number for the backup tail after removal.
2. Whether traffic through the API is excluded from model training, stated separately from whatever applies to their consumer app.
3. A named list of who inside your own account can read request inputs and outputs.
4. What becomes of stored assets when the contract or license ends.

Each of the five publishes some of those, and none of the five had all four on the pages I went through on 8 September 2026. Whichever come back thin are the ones to raise before the integration lands in a sprint, since they get harder to ask once the feature ships.