Launch Sale: Creator and Business plans are discounted for a limited time. View pricing

Get Started

Build your AudioDN setup one decision at a time.

Every AudioDN workflow begins the same way: decide what each upload should become. Then choose how you upload tracks and how listeners play or access them — independently.

You do not need to classify your product as Web, Hybrid, Server-Side, or Mobile. Pick the next choice that changes your setup.

Build your setup Create an account

Browse all documentation

First, decide what each upload should become.

AudioDN processes every uploaded file using the variants configured for your account or collection. Configure these outputs once, and AudioDN creates them automatically whenever new audio arrives.

One unpredictable source upload

Any format, quality, or bitrate

song.wav Lossless

AudioDN processing

  • Reliable playback

    High-quality AAC or MP3

  • Low-bandwidth playback

    Opus or AAC

  • Preview

    30-second preview clip

  • Download

    FLAC or WAV download

  • Waveform or analysis

    Waveform images and analysis data

  • Original

    Preserved when retained

A source file can become several purpose-built outputs. Customer-facing outcomes come first; codec and bitrate choices are just supporting detail.

Create only the outputs your product needs. You can add more variants as your workflow evolves.

Retaining the original upload lets AudioDN generate new variants later, so you can add an output without asking customers to re-upload.

Explore variant types Configure variants in the dashboard

Next, choose how you upload — and how listeners access audio.

These are two independent tasks. Configure one or both. You can upload with components and play with server-created sessions, or any other combination.

Uploading tracks

Choose who creates the upload session, then — if needed — how files are transferred. Upload and playback choices are independent.

Upload and playback choices are independent. A product can upload one way and play audio another way.

Who should create or authorize the upload session?
How should the user transfer the files?

Your upload flow

AudioDN Uploader or (voice) Recorder web components with a Client-Side Upload key

A scoped Client-Side Upload key lives in the page or app → the AudioDN Uploader or (voice) Recorder web component creates the upload session → AudioDN uploads and processes the files.

Credential
Client-Side Upload key
Where the credential lives
In the browser or native app (scoped)
Who decides whether uploading is permitted
The key scope (and optional collection configuration) decides what may be uploaded
Who supplies the interface
AudioDN Uploader or (voice) Recorder web components
Who performs the upload steps
The AudioDN web component performs the individual upload steps
Backend
No backend required
  1. 1 Create a scoped Client-Side Upload key
  2. 2 Add the AudioDN Uploader or (voice) Recorder web component
  3. 3 Users select files or record voice from the microphone
  4. 4 AudioDN creates the session, track(s), and uploads
  5. 5 Wait for processing to finish
  • A Client-Side Upload key can only create upload sessions — not read or delete tracks.
  • Never put an API Access key or URL Signing secret in browser or mobile code.
Uploader web component (voice) Recorder web component API Keys

Your upload flow

Custom client upload with a Client-Side Upload key

A scoped Client-Side Upload key lives in your app → your app creates an upload session → creates a track per file → uploads each file → AudioDN processes the files.

Credential
Client-Side Upload key
Where the credential lives
In the browser or native app (scoped)
Who decides whether uploading is permitted
The key scope decides what may be uploaded
Who supplies the interface
Your custom web or native interface
Who performs the upload steps
Your application performs the individual upload steps
Backend
No backend required
  1. 1 Create a scoped Client-Side Upload key
  2. 2 Create an upload session
  3. 3 Create one track for each file
  4. 4 Upload each file to its returned upload URL
  5. 5 Wait for AudioDN processing
  • A Client-Side Upload key can only create upload sessions — not read or delete tracks.
  • Never put an API Access key or URL Signing secret in browser or mobile code.
  • Each file needs its own track and upload URL. An upload session can authorize many files, but every file still requires a per-track request.
Upload Sessions API API Keys

Your upload flow

Server-created upload session with the AudioDN Uploader or (voice) Recorder web components

Your server approves the upload → creates an upload session → passes the session to the AudioDN Uploader or (voice) Recorder web component → AudioDN uploads and processes the files.

Credential
API Access key
Where the credential lives
On your server only
Who decides whether uploading is permitted
Your server (logins, permissions, quotas, etc.)
Who supplies the interface
AudioDN Uploader or (voice) Recorder web components
Who performs the upload steps
The AudioDN web component performs the individual upload steps
Backend
Backend required
  1. 1 Keep an API Access key on your server
  2. 2 Authorize the uploader in your application
  3. 3 Create a short-lived upload session
  4. 4 Pass the session ID to the AudioDN Uploader or (voice) Recorder web component
  5. 5 AudioDN uploads and processes the files
  • Keep the API Access key on your server only.
  • Pass only the short-lived session ID to the client.
Upload Sessions API Uploader web component API Keys

Your upload flow

Server-created upload session with a custom interface

Your server approves the upload → creates an upload session → your custom interface creates a track per file and uploads each file → AudioDN processes the files.

Credential
API Access key
Where the credential lives
On your server only
Who decides whether uploading is permitted
Your server (logins, permissions, quotas, etc.)
Who supplies the interface
Your custom web or native interface
Who performs the upload steps
Your application performs the individual upload steps
Backend
Backend required
  1. 1 Keep an API Access key on your server
  2. 2 Authorize the uploader in your application
  3. 3 Create a short-lived upload session
  4. 4 Create one track for each file
  5. 5 Upload each file to its returned upload URL
  6. 6 Wait for AudioDN processing
  • Keep the API Access key on your server only.
  • Pass only the short-lived session ID to the client.
  • Each file needs its own track and upload URL. An upload session can authorize many files, but every file still requires a per-track request.
Upload Sessions API API Keys

Playing and accessing tracks

Choose how access is granted, then — if needed — how audio is played. You can mix methods (for example public signed previews and gated play sessions for full tracks).

How should access to the audio be granted?
How should the audio be played?

Your playback flow

AudioDN Player web component with a Client-Side Player key

A scoped Client-Side Player key lives in the page → the AudioDN Player web component creates and renews play sessions → AudioDN streams the permitted variants.

Credential
Client-Side Player key
Where the credential lives
In the browser (scoped)
Where authorization occurs
Key scope (collection, track, and/or variants)
Backend
No backend required
Interface
AudioDN Player web component
API round trip before playback
The player creates sessions automatically — no separate API call from your code
Access model
Scoped client credential — not per-listener server approval
  1. 1 Create a scoped Client-Side Player key
  2. 2 Add the AudioDN Player web component with the key, scope, and id
  3. 3 The player creates and renews play sessions
  4. 4 AudioDN streams the permitted variants
  • A Client-Side Player key can only create play sessions — not manage tracks or collections.
  • Client-Side Player keys cannot manage tracks or collections.
  • Never put an API Access key or URL Signing secret in browser or mobile code.
Player web component API Keys

Your playback flow

Custom player with a Client-Side Player key

A scoped Client-Side Player key lives in your app → your app creates a play session → retrieves playback resources → your custom player streams them.

Credential
Client-Side Player key
Where the credential lives
In the browser or native app (scoped)
Where authorization occurs
Key scope (collection, track, and/or variants)
Backend
No backend required
Interface
Your custom web or native player
API round trip before playback
Yes — create a play session, then fetch playback resources
Access model
Scoped client credential — not per-listener server approval
  1. 1 Create a scoped Client-Side Player key
  2. 2 Create a play session for a track or collection
  3. 3 Fetch signed variant URLs for each track
  4. 4 Play them in your custom media interface
  • A Client-Side Player key can only create play sessions — not manage tracks or collections.
  • Client-Side Player keys cannot manage tracks or collections.
  • Never put an API Access key or URL Signing secret in browser or mobile code.
Play Sessions API API Keys

Your playback flow

Server-created play session with the AudioDN Player web component

Your server checks the listener’s entitlement → creates a play session → passes it to the AudioDN Player web component → AudioDN streams the permitted variants.

Credential
API Access key
Where the credential lives
On your server only
Where authorization occurs
Your server (logins, purchases, subscriptions, permissions)
Backend
Backend required
Interface
AudioDN Player web component
API round trip before playback
Yes — your server creates a play session before playback
Access model
Per-listener entitlement enforcement
  1. 1 Keep an API Access key on your server
  2. 2 Authorize the listener in your application
  3. 3 Create a short-lived play session
  4. 4 Pass the session ID to the AudioDN Player web component
  5. 5 AudioDN streams the permitted variants
  • Keep the API Access key on your server only.
  • Check logins, purchases, subscriptions, or permissions on your server before creating a play session.
  • Pass only the short-lived session ID to the client.
Play Sessions API Player web component API Keys

Your playback flow

Server-created play session with a custom player

Your server checks the listener’s entitlement → creates a play session → returns playback resources → your custom player streams them.

Credential
API Access key
Where the credential lives
On your server only
Where authorization occurs
Your server (logins, purchases, subscriptions, permissions)
Backend
Backend required
Interface
Your custom web or native player
API round trip before playback
Yes — your server creates a play session before playback
Access model
Per-listener entitlement enforcement
  1. 1 Keep an API Access key on your server
  2. 2 Authorize the listener in your application
  3. 3 Create a short-lived play session
  4. 4 Fetch signed variant URLs
  5. 5 Play them in your custom media interface
  • Keep the API Access key on your server only.
  • Check logins, purchases, subscriptions, or permissions on your server before creating a play session.
  • Pass only the short-lived session ID to the client.
Play Sessions API API Keys

Your playback flow

Signed delivery without a play session

Your server signs a delivery URL with a URL Signing key → returns the temporary URL → your media interface streams it directly. No play session is created.

Credential
URL Signing key
Where the credential lives
On your server only
Where authorization occurs
Your server decides who receives a signed URL; possession of the URL grants access until it expires
Backend
Backend required (to sign URLs)
Interface
Your own media interface (not the AudioDN Player web component)
API round trip before playback
No AudioDN API round trip at play time — sign locally and stream from your delivery domain
Access model
Possession of a temporary URL — not per-listener entitlement enforcement
  1. 1 Create a URL Signing key in the dashboard
  2. 2 Keep the signing secret on your server
  3. 3 Sign the delivery URL (HMAC-SHA256)
  4. 4 Return the finished URL to the client
  5. 5 Play it in any media interface that accepts a URL
  • The URL Signing secret must never reach the browser. Sign on the server and return only the finished URL.
  • Anyone with a valid signed URL can stream until it expires. This is not per-listener entitlement enforcement.
  • Signed delivery URLs are for your own media interface — not for the AudioDN Player web component.
  • Signed delivery is a playback option, not an upload method. You still need an upload flow to ingest audio.
Signing Keys API

Ready for the technical details?

Your selections above describe the setup you chose. Open the matching guide for exact steps, credentials, and code examples.

Uploading tracks guide Playing and accessing tracks guide
Integrations overview API reference

Start with the setup that fits. AudioDN can grow with you.

Configure the outputs your product needs, choose upload and playback independently, and add more control when you are ready.

Create an AudioDN account Open the documentation Talk to sales