Who writes the file

Pull it yourself, or let the vendor push it. One word decides which bucket you can even use.

The win from this lesson. You will be able to settle the DuckyCutz R2 question yourself, and to read any vendor's storage docs and say in one line whether it can write into your bucket. About 8 minutes to read, 20 to run the check at the end.

The decision on the table

Yesterday you shipped a nightly cron. Once a day api/recording-sweep.js asks the database "which calls have no audio yet?", fetches each WAV out of VAPI, and writes it into the private Vercel Blob store. VAPI deletes its own copy after 14 days on the pay-as-you-go plan (docs), so the cron has 13 days of slack: it can fail twelve nights running and lose nothing.

The alternative: hand VAPI the keys to a bucket of yours, and it writes each recording in itself as the call ends. No cron, no 14-day race. That is what VAPI calls custom storage, and it is real: by default recordings go to VAPI's own Cloudflare R2 bucket, and you can point them at your own bucket in AWS S3, Google Cloud Storage, Cloudflare R2 or Supabase (S3 setup, R2 setup).

Two shapes for the same job. Learn to see them and this decision stops being about VAPI.

pull-and-bankVendor holds it. A cron of yours fetches and stores it. Today's DuckyCutz.

vendor-pushYou register bucket keys. The vendor writes it the moment it exists.

The word that decides the bucket: S3-compatible

For a vendor to write into your storage, it has to be able to speak to it. Almost every vendor speaks exactly one storage language: the S3 API. Amazon's interface for "put this object, get that object" became the industry's common tongue, so other storage products copy the shape and advertise themselves as S3-compatible. Cloudflare R2 is (docs). Supabase Storage is (VAPI even documents it).

Vercel Blob is not, and this is the part worth getting exactly right, because the sloppy version of it will mislead you later:

Vercel Blob runs on Amazon S3 underneath and still cannot be VAPI's custom storage. Its own docs say the storage is S3-backed and that the pricing matches S3's (pricing), but the only way in is @vercel/blob: put(), get(), del(). There is no S3 endpoint and no access-key pair to hand out. Being built on S3 is not the same as speaking S3. No outside service can write into it, only your own code.

That is why the migration is even a question. It is not that Vercel Blob is worse storage. It is that it has no door for anyone but you.

What actually changes

	pull-and-bank (today)	vendor-push (R2)
Cron	One, plus its 300s budget	None. Deleted.
Race against the 14-day window	Yes, with 13 days of slack	Gone entirely
Who names the object key	You: `calls/<call id>.wav`	VAPI, its way
How `recording_path` is filled	Returned by your own `put()`	Derived, or read off the webhook
A failed write	Row keeps NULL, retried tomorrow	Nobody's retry queue
Portal playback	`get()` streams the bytes	Rewrite: S3 client or presigned URL
The 173 MB already stored	Where it is	Has to be copied over

Money is not on that list on purpose. A year of calls is about 5 GB. R2 standard storage is $0.015 per GB-month with no egress charge (pricing), so about 8 cents a month. Vercel Blob is $0.023 per GB-month, about 12 cents. The entire annual saving is roughly fifty cents. Cost cannot decide this. Failure modes have to.

Note the direction of the failure-mode trade. Today's risk is a sweep that silently stops and quietly loses audio older than 14 days, and you would find out from a gap in the portal. The vendor-push risk is a write into your bucket that silently fails, and you would find out the same way. You are not removing the failure, you are moving it to a place you cannot instrument. That is a real cost, and the thing that buys it back is that there is no longer a window: the file either landed at the end of the call or never existed.

The correction hiding in the docs

The framing "set recordingUseCustomStorageEnabled: true" is slightly off, and the real version is more useful. That flag lives on assistant.artifactPlan and already defaults to true (docs). It does not mean "use my bucket". It means "use my bucket if storage credentials are configured". No credential registered, so it quietly falls back to VAPI's own R2 today.

So the work is not a flag. It is one credential, registered once, under Provider Credentials → Cloud Providers in the VAPI dashboard, or through the API. After that every new call lands in your bucket with no code change at all on your side.

Unverified, and it is the crux. I could not find a primary source that states the exact object key VAPI writes, nor whether that key comes back to you in the end-of-call-report webhook. Everything above about which providers work and which flag governs it is documented. This is not, so do not build on an assumption about it. The next section settles it in 20 minutes by observation, which is the only trustworthy way.

Your turn: 20 minutes, on the sandbox account

Do not touch the production VAPI account. This is exactly the case the test-account-first rule exists for: a mis-set credential on prod means recordings land somewhere you are not reading.

(5 min) Make an R2 bucket, dc-recordings-test. Cloudflare dashboard → R2 → Create bucket. Then Manage R2 API Tokens → Create API Token, scoped to that one bucket. Copy the Access Key ID and Secret; the secret is shown once.
(3 min) Register it on the sandbox VAPI account: Provider Credentials → Cloud Providers → S3. Region is the literal string auto and the endpoint is https://<ACCOUNT_ID>.r2.cloudflarestorage.com, which is R2's S3-compatible address (docs).
(2 min) Place one test call to the sandbox number. Say two sentences and hang up.
(5 min) Look at what landed. In the R2 object browser, or with the AWS CLI pointed at R2:
```
aws s3 ls s3://dc-recordings-test/ --recursive \
  --endpoint-url https://<ACCOUNT_ID>.r2.cloudflarestorage.com
```
Write down the exact key. Does the call id appear in it? Is it a WAV or an MP3? That one string is the whole answer to "can recording_path be derived, or must it be read off the webhook?"
(5 min) Check the webhook. Find that call's end-of-call-report in the relay logs and look at what the recording URL now points to. If it points into your bucket, you never need to derive anything: you store what you are handed, exactly as you do now.

Come back with the key string and the webhook field. Those two facts decide the migration, and nothing you can read decides them as reliably as one test call.

Check yourself

What makes your storage usable by an outside vendor?

Move to vendor-push and the thing you give up is:

recordingUseCustomStorageEnabled defaults to true, so:

Read this next

Primary source: Call recording, logging and transcribing on VAPI's docs. It is the one page that holds the whole artifactPlan, the storage flags and the retention rules together. Read it before you register anything, and read it in preference to any blog post, including this lesson.

Terms used here are pinned in the object storage glossary. The related decision, why the call record moved into your own Postgres at all, is written up in plans/duckycutz-own-call-database.md.

Ask your teacher. Anything unclear, ask, and ask for it as an analogy plus one DuckyCutz example rather than a longer version of the same words. The two questions this lesson is most likely to have left open: what a presigned URL actually is, and how the portal's playback route would change under R2.

Mission Glossary →