TranscribeAudio: one backend, several front doors

transcribeaudio.ai · examined 2026-08-21 · figures carry a confidence grade (A/B/C/D), explained at the end

What it is

Not a standalone product. It is the newest front door on a Chinese team’s network of AI tool sites, and it has been open for under six weeks.

It shares a FastAPI backend with its sibling videototranscript.com — 186 endpoints each, 113 of them identical, every one annotated in Chinese. That backend has a complete and visibly exercised billing system: subscriptions, credit packs, refunds, dunning for past-due accounts. The site in front of it has no way to pay for anything.

Read: deliberately free while it accumulates traffic, with the switch already wired.

1. Whose it is

1.1 The API documentation is public, and it is annotated in Chinese

api.transcribeaudio.ai/api/openapi.json is served to anyone, 186 endpoints (A, recomputable from the stored copy):

POST /api/at/audio-to-text/create-transcription    声音转录创建接口
POST /api/at/audio-to-text/manager-role            角色管理层
POST /api/aliyun_translate/create-job              阿里云翻译接口
POST /api/at/youtube-extraction/create-job         YouTube无字幕视频提取创建接口
POST /api/pai/v1/webhook/common                    通用Replicate回调

1.2 Errors come back bilingual

Send an empty request — parameter validation, no side effects:

{"code":400301,"result":null,"message":{"en":"Params error","zh":"参数异常"}}

1.3 The infrastructure is Alibaba Cloud

Response headers carry x-oss-request-id and x-oss-ec, and the troubleshooting link points at api.alibabacloud.com. Origin is Alibaba OSS with Cloudflare in front.

Front-end telemetry posts straight to Alibaba SLS, configuration hardcoded in the bundle:

{host:"us-west-1.log.aliyuncs.com", project:"pai-us", logstore:"web-transcribeaudio"}

project: pai-us, together with /api/pai/v1/webhook/ in the API, points at Alibaba’s PAI machine-learning platform.

2. Stack (A — measured unless noted)

Layer	Evidence	Read
Front end	`/_nuxt/*.js`, `_payload.json`	Nuxt (Vue), statically generated
Hosting	`x-oss-request-id` plus `server: cloudflare`	Alibaba OSS behind Cloudflare
Backend	`{"detail":"Method Not Allowed"}`, openapi `title: FastAPI`	Python FastAPI on its own API subdomain
Orchestration	`/zfhealth/liveness`	Kubernetes liveness probe
Models	`通用Replicate回调`, `/bridge/newapi/chat`	Replicate for inference, New API as an LLM gateway
Translation	`/api/aliyun_translate/*`	Alibaba machine translation for the locales
Telemetry	Alibaba SLS, GA4, Microsoft Clarity	three in parallel
Auth	`/api/login/login-google`, email codes	Google OAuth plus their own email login
Assets	`assets.transcribeaudio.ai`	separate asset domain

No Western PaaS anywhere. No Vercel, no Supabase, no Clerk, no Stripe. A full Alibaba Cloud stack with Cloudflare in front, which is the standard configuration for a Chinese team selling abroad.

The consequence is that fixed costs are much higher than for something like AdsCreator on a Vercel monolith. A Kubernetes cluster, object storage, a log service and a separate API domain all need somebody looking after them. Which is exactly why the sites come in bulk: those costs only make sense divided by N.

3. One backend, several domains

The homepage bundle leaks a domain that does not belong to it: assets.videototranscript.com. Following that (A — both OpenAPI documents and both sitemaps are archived locally):

	transcribeaudio.ai	videototranscript.com
Architecture	Alibaba OSS + Cloudflare	identical
SLS logstore	`web-transcribeaudio`	`web-videototranscript`
SLS project	`pai-us`	the same one
API prefix	`/api/at/` (audio transcribe)	`/api/vt/` (video transcript)
GA4 property	G-M22EDVNYL4	G-T7064ZTSF4 (counted separately)
Endpoints	186	186, sharing 113
Own business routes	`/at/` 48	`/vt/` 86
Upload ceiling	250MB	5GB
Sitemap	21 URLs	21 URLs

One codebase deployed twice, each site exposing the full route set for its own line of business. They also serve JS chunks with identical names and hashes (DlAUqK2U.js), so it is one monorepo.

One claim this revision retracts

The first pass called videototranscript the primary site, and one of the reasons given was that it is larger. Both sitemaps are 21 URLs. They are equally small. The case for it being primary comes down to three things instead, and those three hold:

86 business endpoints against 48
a 5GB upload ceiling against 250MB, a factor of twenty
different pages, which is the interesting one

What is actually in those 21 URLs

Both sites are three paths across seven locales (English by default, plus de / es / fr / pt / jp / kr — the codes really are jp and kr, not ja and ko). The three paths are not the same:

	The three paths
transcribeaudio	home, `/privacy-policy/`, `/terms-of-use/`
videototranscript	home, `/history/`, `/youtube-transcript-generator/`

transcribeaudio has exactly one real content page; the other two are legal boilerplate. It has not built a single landing page yet. The sibling already has /youtube-transcript-generator/, which is a page written to rank for a query. That difference says more about which site matters than the endpoint counts do.

One more thing: videototranscript links to /blog/ twice from its homepage, and there is no blog entry anywhere in its sitemap. For a network that lives on search, that is an oversight.

The backend does much more than transcription

186 endpoints by prefix (A, measured):

asset            49   files, folders, trash, favourites — full asset management
at               48   audio transcription (this site)
text-to-speech   15   speech synthesis, with voice-pack management
vt               13   video transcription (86 on the sibling)
favorite         13
login            10
management        9   internal admin
payment           7   billing
youtube-plugins   5   YouTube plugins, so probably a browser extension somewhere
aliyun_translate  4
share             3
doc-recognition   2   document recognition
article-crawling  1   URL content extraction

Worth noting that videototranscript’s 186 endpoints contain no login and no favourites at all. Two readings: either it is a purely anonymous tool with no accounts, or its document is trimmed more aggressively. Since transcribeaudio ships an AuthModal component in its bundle and the sibling does not, the first is more likely.

transcribeaudio.ai is one entrance to a platform. Who owns the platform is not established from public information.

4. Six weeks old

Current registration: 2026-07-17 (the sibling, 07-01), registrar Cloudflare
First Wayback capture of the current build: 2026-08-14
Sitemap lastmod: 08-14 here, 08-19 on the sibling

Both domains existed before — transcribeaudio.ai has captures from 2024, videototranscript.com from 2021 — so these are expired domains picked up for their age, the same play AdsCreator made.

Against AdsCreator’s 534 pages, this is 21. Very early.

5. How it will make money, once it decides to

5.1 Nothing to pay for

Page title: Free Online Audio to Text Converter – No Sign-Up
No pricing, no credits, no upgrade button anywhere; the string pricing appears zero times in the homepage HTML (A, measured)
No Stripe, Paddle, Creem or LemonSqueezy in the bundle

5.2 The billing system behind it is complete and in use

POST /api/payment/subscription/pay-url             start a subscription
POST /api/payment/credits-addon/pay-url            buy a credit pack
POST /api/payment/subscription/unsubscribe         cancel
POST /api/payment/subscription/stop-past-due-bill  handle a past-due account
POST /api/management/payment/update-balance        adjust a balance by hand
POST /api/management/payment/subscription/upgrade  upgrade (1 = now, 0 = next cycle)

Balances are tracked in four buckets: free_quotas, subscription_quotas, permanent_credits, subscription_credits. There is a refund flag, an immediate-cancellation flag, and a payment-channel field.

None of this was written last month. It was inherited from something already operating. Nobody builds dunning and manual balance adjustment for a product with no customers — those two features only get written after somebody has actually failed to pay and then argued about it with support.

5.3 How long it can afford to be free (C — my estimate)

The first pass never did this arithmetic, and it is the most direct way to judge how long the free period can last.

Transcription is a marginal-cost business. Volume costs money in a way software does not:

Item	Estimate	Note
ASR inference	$0.003–0.006 per audio minute	API rates in 2026; self-hosted is lower
Storage	negligible	OSS is cheap and objects can expire
Translation	negligible at this volume	Alibaba MT, charged per character

A ten-minute file costs roughly $0.03–0.06. At a thousand transcriptions a day that is $30–60 daily, so $900–1,800 a month. For a team with an existing business that is nothing, which means the free period can run for a very long time. There is no cost pressure forcing a decision.

Two things would change that answer. The 250MB ceiling here (5GB on the sibling) means long files can push the per-job cost up sharply. And those fifteen text-to-speech endpoints matter: synthesis costs an order of magnitude more than recognition, so if any site in the network starts giving TTS away, the burn looks completely different.

5.4 The read

transcribeaudio.ai is deliberately free while it builds traffic. Which makes the monitoring script’s job simple: the moment a price appears on the front end, the free period is over. The secondary signal is the sitemap going from three paths to a dozen, which would mean they have started taking SEO seriously here.

6. Customers, revenue

For this site, almost certainly neither:

six weeks old, 21 pages, no way to pay
three unattributed five-star testimonials on the homepage, no names, no logos (D)
nothing anywhere — Reddit, X, review sites

But the question does not really apply. This is not a business, it is an entrance. The revenue lives with the platform, and the platform’s identity is not established from public information.

What is established: the backend has subscriptions, credits, refunds and dunning, and nobody builds those for a product that earns nothing.

7. Two things worth saying

7.1 The admin API is in the public documentation

/api/management/* sits in the same publicly served openapi.json as the user-facing routes:

POST /api/management/login/delete-account
POST /api/management/login/get-userinfo-by-email
POST /api/management/login/pag-query-user-info
POST /api/management/payment/update-balance
POST /api/management/payment/subscription/unsubscribe

These are almost certainly authenticated — this analysis only read public documents and called no management endpoint. But putting admin routes in the same document you serve to the world is surface area you did not need to expose. /redoc and /api/docs are open too, which publishes the full capability list of the backend.

It also says something about how tightly the team works, which is useful when judging a competitor’s execution.

7.2 Commodity product, played on volume

The transcription category is already crowded: Transkriptor, TranscribeToText, VideoTranscriber. The response here is not differentiation. It is one backend behind many domains, each named for a different keyword, each taking a slice of search. No single site has to win; the network only has to cover its costs in aggregate.

Moat, honestly graded

Fake: transcription itself. Wire up an ASR API and you have it.
Weak: domain age, multilingual coverage.
Real: how far the shared backend has been engineered. Forty-nine asset endpoints, four kinds of balance, dunning — those are shaped by real operation, and a new team’s first site will not have them.
If a model vendor ships this: it already did. Assistants transcribe audio directly. What keeps this network alive is no login, free, and findable in search, not technology.

What it would take to build (C — my estimate)

Another front door on the network: a Nuxt template with locales, one to two weeks. That is the whole advantage — replication is nearly free.

The shared backend from scratch — asset management, four balance types, billing and refunds, Kubernetes, a multi-model gateway — is three to six months and a small team. Not a solo project.

8. Against AdsCreator

Two entirely different models for selling software abroad:

	AdsCreator	TranscribeAudio
Team	US, serial founder with an eight-figure agency	Chinese team running a site network
Stack	Next.js, Vercel, Stripe	Nuxt, Alibaba OSS, FastAPI, Replicate
Fixed cost	near zero, nothing self-run	high, but divided by N sites
Marginal cost	$0.03–0.09 per image	$0.003–0.006 per audio minute
Play	one site, deep — 534 pages plus GEO	many sites, wide — one backend, N front doors
Differentiation	domain knowledge frozen into enums	essentially none; coverage instead
Money	charging from day one	free first, switch already wired
In common	both bought aged domains, both live on SEO, neither buys ads

Copyability: one person can get AdsCreator to about seventy percent in two or three months. One person can clone a single site here in a week, and cannot build the shared backend at all — that is three to six months and a team.

9. Conclusion

In one line: this is a business of scale, not a business of product. Any single site is worthless on its own; the whole is a machine for converting search traffic into subscriptions. The risk is not competition. It is search engines deciding what to do about site networks, and general assistants absorbing “transcribe this audio” as a thing you no longer need a website for.

If I were building against it: do not copy the network — that requires a backend somebody has already run in anger. Copy the order of operations: build billing, ledgers and refunds first, and decide later when to expose them. The multilingual static generation is also worth taking. One Nuxt build producing seven locales costs almost nothing, and most independent developers ship English only.

Where I could be wrong:

Assumption one: free is a strategy, not an inability. My basis is the complete billing system. But that backend could be bought, or built by a contractor, and the team may simply not have wired it up yet. Watch the home.pricing.plans i18n key: if months pass with the front end still not rendering it while other features ship, the answer is that they cannot connect it rather than that they choose not to.
Assumption two: both sites belong to one team. The evidence is strong — same SLS project, identically hashed chunks, 186 mirrored endpoints. In principle a white-label vendor could have sold the same system to two customers. Check the payment entity and the company name in each site’s terms.
Assumption three: the platform earns real money. This is inferred entirely from the presence of dunning, with nothing direct behind it. If that backend turns out to be adapted from an open-source project or a commercial template, the inference collapses. Search for the /api/at/ and /api/vt/ prefixes with those Chinese annotations and see whether a shared codebase surfaces publicly.

Grades and sources

A — measured: collected and verified directly, recomputable from the stored copies
B — checked: corroborated across sources
C — estimated: my arithmetic, with the working shown
D — asserted: the site’s own copy, no defined basis

Measured: transcribeaudio.ai homepage, sitemap.xml, robots.txt, _nuxt bundle; api.transcribeaudio.ai/api/openapi.json (186 endpoints, public); the same set for videototranscript.com for comparison; HTTP response headers; Wayback capture history and whois registration dates.

Not established: who owns the platform, either site’s real traffic, the home.pricing.plans i18n key (it lives in a _nuxt chunk this snapshot did not preserve — worth archiving next run), which ASR model is in use, and whether the browser extension implied by those five youtube-plugins endpoints actually exists.

Method note: read-only collection and public documents only. No write operations, no management endpoints, nothing published that would function as an attack recipe.