Media Handling - WhatsApp Rust

Overview

This guide covers uploading and downloading media (images, videos, audio, documents, stickers) with automatic encryption and decryption.

Downloading Media

From message objects

Download media directly from message types that implement Downloadable:

use whatsapp_rust::wacore::download::Downloadable;
use whatsapp_rust::client::Client;
use whatsapp_rust::wacore::types::events::InboundMessage;

match event {
    Event::Messages(batch) => {
        for InboundMessage { message, info, .. } in batch.iter() {
            // Image
            if let Some(img) = message.image_message.as_option() {
                let data = client.download(img, whatsapp_rust::download::DownloadLimits::default()).await?;
                std::fs::write("image.jpg", data)?;
            }

            // Video
            if let Some(video) = message.video_message.as_option() {
                let data = client.download(video, whatsapp_rust::download::DownloadLimits::default()).await?;
                std::fs::write("video.mp4", data)?;
            }

            // Audio
            if let Some(audio) = message.audio_message.as_option() {
                let data = client.download(audio, whatsapp_rust::download::DownloadLimits::default()).await?;
                let ext = if audio.ptt() { "ogg" } else { "mp3" };
                std::fs::write(format!("audio.{}", ext), data)?;
            }

            // Document
            if let Some(doc) = message.document_message.as_option() {
                let data = client.download(doc, whatsapp_rust::download::DownloadLimits::default()).await?;
                let filename = doc.file_name.as_deref().unwrap_or("document");
                std::fs::write(filename, data)?;
            }

            // Sticker
            if let Some(sticker) = message.sticker_message.as_option() {
                let data = client.download(sticker, whatsapp_rust::download::DownloadLimits::default()).await?;
                std::fs::write("sticker.webp", data)?;
            }
        }
    }
    _ => {}
}

See Download API reference for full details.

Streaming Download

For large files, use streaming to avoid memory overhead:

use std::fs::File;

if let Some(video) = message.video_message.as_option() {
    let file = File::create("video.mp4")?;
    let file = client.download_to_writer(video, file, whatsapp_rust::download::DownloadLimits::default()).await?;
    println!("Video downloaded and verified");
}

See Download API reference for streaming details.

With a streaming HTTP adapter and a file destination, download_to_writer keeps bounded crypto/read state. This excludes adapter/TLS buffers and destination storage. With default limits, non-streaming adapters can buffer the whole response before writing it. Explicit byte limits require streaming and refuse a non-streaming adapter before HTTP. See download limits.

From raw parameters

Download media when you have the raw encryption parameters:

use whatsapp_rust::wacore::download::MediaType;
use whatsapp_rust::download::DownloadParams;

let params = DownloadParams::encrypted(
    "/v/t62.1234-5/...",  // direct_path
    &media_key,            // media_key (32 bytes)
    &file_sha256,          // file_sha256
    &file_enc_sha256,      // file_enc_sha256
    12345,                 // file_length
    MediaType::Image,      // media_type
)?;

let data = client.download(&params, whatsapp_rust::download::DownloadLimits::default()).await?;

std::fs::write("downloaded.jpg", data)?;

See Download API reference for raw parameter downloads.

Streaming from raw parameters

let params = DownloadParams::encrypted(
    direct_path,
    &media_key,
    &file_sha256,
    &file_enc_sha256,
    file_length,
    MediaType::Video,
)?;

let file = File::create("large_video.mp4")?;
let file = client.download_to_writer(&params, file, whatsapp_rust::download::DownloadLimits::default()).await?;

See Download API reference for streaming from raw parameters.

Downloading without an active session

Client::download and its variants need a connected Client for most media; they ask the server for CDN hosts (cached and refreshed automatically, not fetched on every call). The exception is static_url media (newsletter/channel content), which skips that entirely; see the Download API reference for details. If you’ve persisted a message’s CDN fields (for example as a DownloadParams) and want to fetch that media later, after the session that received it has disconnected, use MediaDownloader instead. It needs only an HttpClient and a Runtime; no Client, no pairing:

use std::sync::Arc;
use whatsapp_rust::wacore::download::MediaType;
use whatsapp_rust::download::{DownloadParams, MediaDownloader};

// Same HttpClient/Runtime you'd pass to ClientBuilder — no session required.
let downloader = MediaDownloader::with_default_hosts(http_client.clone(), runtime.clone());

let params = DownloadParams::encrypted(
    direct_path,
    &media_key,
    &file_sha256,
    &file_enc_sha256,
    file_length,
    MediaType::Image,
)?;

let data = downloader.download(&params, whatsapp_rust::download::DownloadLimits::default()).await?;

MediaDownloader uses the same streaming/buffered behavior and host failover as client downloads. It cannot refresh the host list through a session. A reference rejection returns a typed MediaDownloadError. Supply hosts with MediaRoute::new(hosts) or use the default-host convenience; download routes carry no auth token.

Thumbnails

Thumbnails are not generated by the library — you provide them as raw JPEG bytes when constructing media messages. WhatsApp clients use these thumbnails as low-resolution previews while the full media is downloading.

Setting thumbnails on media messages

Set the jpeg_thumbnail field on image, video, or document messages:

use whatsapp_rust::waproto::whatsapp as wa;

let upload = client.upload(image_data, MediaType::Image, Default::default()).await?;

let message = {
    let mut value = wa::Message::default();
    value.image_message = buffa::MessageField::some({
        let mut value = wa::message::ImageMessage::default();
        value.url = Some(upload.url.clone());
        value.direct_path = Some(upload.direct_path.clone());
        value.media_key = Some(upload.media_key_vec());
        value.file_sha256 = Some(upload.file_sha256_vec());
        value.file_enc_sha256 = Some(upload.file_enc_sha256_vec());
        value.file_length = Some(upload.file_length);
        value.media_key_timestamp = Some(upload.media_key_timestamp);
        value.mimetype = Some("image/jpeg".to_string());
        value.jpeg_thumbnail = Some(thumbnail_bytes); // Raw JPEG bytes
        value.width = Some(1920);
        value.height = Some(1080);
        value
    });
    value
};

Thumbnail fields by message type

Message type	Inline thumbnail field	Server-hosted thumbnail fields
`ImageMessage`	`jpeg_thumbnail`	`thumbnail_direct_path`, `thumbnail_sha256`, `thumbnail_enc_sha256`
`VideoMessage`	`jpeg_thumbnail`	`thumbnail_direct_path`, `thumbnail_sha256`, `thumbnail_enc_sha256`
`DocumentMessage`	`jpeg_thumbnail`	`thumbnail_direct_path`, `thumbnail_sha256`, `thumbnail_enc_sha256`
`StickerMessage`	`png_thumbnail`	—

Inline thumbnails (jpeg_thumbnail / png_thumbnail) are embedded directly in the encrypted message payload. Server-hosted thumbnail fields (thumbnail_direct_path, etc.) reference a separately uploaded thumbnail that clients can download independently. For most use cases, inline thumbnails are sufficient.

Reusing thumbnails from incoming messages

When re-uploading media (for example, after processing or transcoding), you can clone the thumbnail from the original message:

if let Some(img) = message.image_message.as_option() {
    let data = client.download(img, whatsapp_rust::download::DownloadLimits::default()).await?;
    let upload = client.upload(data, MediaType::Image, Default::default()).await?;

    let reply = {
        let mut value = wa::Message::default();
        value.image_message = buffa::MessageField::some({
            let mut value = wa::message::ImageMessage::default();
            value.url = Some(upload.url.clone());
            value.direct_path = Some(upload.direct_path.clone());
            value.media_key = Some(upload.media_key_vec());
            value.file_sha256 = Some(upload.file_sha256_vec());
            value.file_enc_sha256 = Some(upload.file_enc_sha256_vec());
            value.file_length = Some(upload.file_length);
            value.media_key_timestamp = Some(upload.media_key_timestamp);
            value.mimetype = img.mimetype.clone();
            value.jpeg_thumbnail = img.jpeg_thumbnail.clone(); // Reuse from original
            value.height = img.height;
            value.width = img.width;
            value
        });
        value
    };
}

If you don’t need to modify the media, use CDN reuse instead — it forwards the entire message (including thumbnails) without downloading or re-uploading anything.

Downloading link thumbnails

The LinkThumbnail variant in MediaType supports downloading thumbnails for URL previews in ExtendedTextMessage:

use whatsapp_rust::wacore::download::MediaType;
use whatsapp_rust::download::DownloadParams;

// LinkThumbnail uses HKDF info "WhatsApp Link Thumbnail Keys"
let params = DownloadParams::encrypted(
    thumbnail_direct_path,
    &thumbnail_media_key,
    &thumbnail_sha256,
    &thumbnail_enc_sha256,
    thumbnail_length,
    MediaType::LinkThumbnail,
)?;

let thumbnail = client.download(&params, whatsapp_rust::download::DownloadLimits::default()).await?;

Forwarding media via CDN reuse

When you receive a media message (image, video, audio, document, sticker), you can “forward” it by reusing the original CDN fields directly — no download or re-upload needed. This is instant regardless of file size because no media bytes are transferred. The technique works because every media message contains all the CDN metadata (url, direct_path, media_key, file_sha256, etc.) needed for recipients to fetch the blob. You simply clone those fields into a new wa::Message and call send_message:

use whatsapp_rust::waproto::whatsapp as wa;

/// Reuses the original CDN blob, only swaps the caption.
/// Instant regardless of file size — no download or re-upload.
fn forward_image(original: &wa::message::ImageMessage) -> wa::Message {
    {
        let mut value = wa::Message::default();
        value.image_message = buffa::MessageField::some({
            let mut value = original.clone(); // Preserve the original media metadata.
            value.caption = Some("Forwarded image".to_string());
            value
        });
        value
    }
}

// In your message handler:
if let Some(img) = message.image_message.as_option() {
    let forwarded = forward_image(img);
    client.send_message(destination_jid, forwarded).await?;
}

The same pattern works for any media type:

// Forward a video, keeping all CDN fields intact
if let Some(vid) = message.video_message.as_option() {
    let forwarded = {
        let mut value = wa::Message::default();
        value.video_message = buffa::MessageField::some({
            let mut value = vid.clone();
            value.caption = Some("Forwarded video".to_string());
            value
        });
        value
    };
    client.send_message(destination_jid, forwarded).await?;
}

Only use download + upload when you need the plaintext bytes (processing, transcoding, re-encoding). To forward existing media unchanged, reuse the original message’s CDN fields directly.

When CDN reuse won’t work

CDN URLs expire after some time. If the original media URL has expired, recipients won’t be able to download it. In that case, use media reupload to request the server to provide a fresh download path, or fall back to downloading and re-uploading the media.

Uploading Media

Basic Upload

use whatsapp_rust::wacore::download::MediaType;
use whatsapp_rust::upload::UploadResponse;

// Read file data
let data = std::fs::read("photo.jpg")?;

// Upload with automatic encryption
let upload: UploadResponse = client.upload(data, MediaType::Image, Default::default()).await?;

println!("URL: {}", upload.url);
println!("Direct path: {}", upload.direct_path);
println!("File SHA256: {:?}", upload.file_sha256);

See Upload API reference for full details.

Using upload response in messages

The whatsapp_rust::media module turns an UploadResponse into a ready-to-send wa::Message, so you don’t hand-assemble the CDN/crypto fields (url, direct_path, media_key, the two SHA-256 hashes, file_length, media_key_timestamp, streaming_sidecar):

use whatsapp_rust::wacore::download::MediaType;
use whatsapp_rust::media::{self, ImageOptions};

let upload = client.upload(image_data, MediaType::Image, Default::default()).await?;

let message = media::image_message(upload, {
    let mut options = ImageOptions::default();
    options.caption = Some("Check out this image!".to_string());
    options
});

let result = client.send_message(to, message).await?;

media::video_message, media::document_message, and media::audio_message work the same way with their own options structs (and carry the streaming sidecar for video/audio). See media message builders.

Building the message by hand

You can still assemble the proto yourself when you need a field the options structs don’t expose (e.g. explicit width/height):

use whatsapp_rust::waproto::whatsapp as wa;

let upload = client.upload(image_data, MediaType::Image, Default::default()).await?;

let message = {
    let mut value = wa::Message::default();
    value.image_message = buffa::MessageField::some({
        let mut value = wa::message::ImageMessage::default();
        value.url = Some(upload.url.clone());
        value.direct_path = Some(upload.direct_path.clone());
        value.media_key = Some(upload.media_key_vec());
        value.file_sha256 = Some(upload.file_sha256_vec());
        value.file_enc_sha256 = Some(upload.file_enc_sha256_vec());
        value.file_length = Some(upload.file_length);
        value.media_key_timestamp = Some(upload.media_key_timestamp);
        value.mimetype = Some("image/jpeg".to_string());
        value.caption = Some("Check out this image!".to_string());
        value.width = Some(1920);
        value.height = Some(1080);
        value
    });
    value
};

let result = client.send_message(to, message).await?;

Sending media as an album

You can group multiple images and/or videos into an album. See Sending Messages - Album messages for a full walkthrough of the parent/child album pattern using AlbumMessage and wrap_as_album_child.

Resumable uploads

For files 5 MiB or larger, the client automatically checks whether a previous upload of the same file exists on the CDN before uploading the full payload. This avoids re-uploading data that the server already has. The resume check flow works as follows:

The client sends a ?resume=1 probe to the CDN for each host
If the server responds with complete, the existing URL is returned immediately — no upload occurs
If the server responds with a byte offset, only the remaining bytes are uploaded using the file_offset query parameter
If the server responds with not found (or the check fails), a full upload proceeds

Resumable upload detection is fully transparent. You call client.upload() the same way regardless of file size. The resume check is non-fatal — if it fails for any reason, the client falls back to a full upload.

// Large files automatically use resumable upload logic
let video_bytes = std::fs::read("large_video.mp4")?; // e.g., 50 MiB
let upload = client.upload(video_bytes, MediaType::Video, Default::default()).await?;
// If a partial upload existed, only the remaining bytes were sent

Media Types

Available media types

pub enum MediaType {
    Image,
    Video,
    Audio,
    Document,
    History,
    AppState,
    Sticker,
    StickerPack,
    StickerPackThumbnail,
    LinkThumbnail,
    ProductCatalogImage,
    MusicArtwork,
    NewsletterMusicArtwork,
}

Media type properties

use whatsapp_rust::wacore::download::MediaType;

// Get MMS type for upload URLs
let mms_type = MediaType::Image.mms_type();
// Returns: "image", "video", "audio", "document"

// Get app info string for HKDF key derivation
let info = MediaType::Video.app_info();
// Returns: "WhatsApp Video Keys"

// Get upload path for CDN routing
let path = MediaType::Image.upload_path();
// Returns: "/mms/image"

// Check if media type uses E2E encryption
let encrypted = MediaType::ProductCatalogImage.is_encrypted();
// Returns: false (product catalog images are unencrypted)

ProductCatalogImage and NewsletterMusicArtwork are explicitly plaintext media types. For downloads of other types, key presence selects encryption, except MusicArtwork, which always requires it. Use DownloadParams::plaintext for stored newsletter metadata without a key. Product catalog images upload to /product/image.

Encryption Details

Upload Encryption

Media is automatically encrypted before upload:

Generate random 32-byte media_key
Derive encryption keys using HKDF-SHA256:
- IV: 16 bytes
- Cipher key: 32 bytes
- MAC key: 32 bytes
Encrypt with AES-256-CBC
Append HMAC-SHA256 MAC (10 bytes)
Compute SHA256 hashes of plaintext and ciphertext

// Encryption happens automatically in upload()
let data = std::fs::read("file.pdf")?;
let upload = client.upload(data, MediaType::Document, Default::default()).await?;

// The UploadResponse contains all encryption metadata
// media_key, file_sha256, file_enc_sha256 are [u8; 32] arrays
println!("Media key: {:?}", upload.media_key);
println!("File length: {} bytes", upload.file_length);

Chunk-based encryption with MediaEncryptor

MediaEncryptor provides a chunk-based API for encrypting media incrementally. Unlike encrypt_media_streaming, it doesn’t require a sync Read source — you can feed plaintext in arbitrarily sized chunks, making it suitable for async streams and network sources:

use whatsapp_rust::wacore::upload::MediaEncryptor;
use whatsapp_rust::wacore::download::MediaType;

let mut enc = MediaEncryptor::new(MediaType::Video)?;
let mut encrypted = Vec::new();

// Feed plaintext in any chunk size
for chunk in video_chunks {
    enc.update(&chunk, &mut encrypted);
}

// Finalize: PKCS7 pad + append 10-byte HMAC-SHA256 MAC
let info = enc.finalize(&mut encrypted)?;
// info.media_key, info.file_sha256, info.file_enc_sha256, info.file_length

You can also write directly to a file or writer instead of buffering in memory:

let mut enc = MediaEncryptor::new(MediaType::Video)?;
let mut writer = File::create("large_video.enc")?;

for chunk in video_chunks {
    enc.update_to_writer(&chunk, &mut writer)?;
}

let info = enc.finalize_to_writer(&mut writer)?;

See Upload API reference for full details.

Streaming encryption from a reader

For sync Read sources, encrypt_media_streaming wraps MediaEncryptor and reads in 8KB chunks:

use whatsapp_rust::wacore::upload::encrypt_media_streaming;
use whatsapp_rust::wacore::download::MediaType;
use std::fs::File;

let reader = File::open("large_video.mp4")?;
let writer = File::create("large_video.enc")?;

let info = encrypt_media_streaming(reader, writer, MediaType::Video)?;
// info.media_key, info.file_sha256, info.file_enc_sha256, info.file_length

See Upload API reference for full details.

Download Decryption

Decryption is automatic when downloading:

Fetch encrypted data from WhatsApp CDN
Verify MAC (last 10 bytes)
Decrypt with AES-256-CBC
Verify plaintext SHA256
Return decrypted data

// Decryption happens automatically in download()
let data = client.download(image_message, whatsapp_rust::download::DownloadLimits::default()).await?;
// `data` is already decrypted and verified

Never skip SHA256 verification! The library automatically verifies both encrypted and decrypted hashes to ensure data integrity.

Error Handling

Download Errors

use whatsapp_rust::{Client, download::{ClientDownloadError, Downloadable}};

async fn safe_download(
    client: &Client,
    downloadable: &dyn Downloadable,
) -> Result<Vec<u8>, ClientDownloadError> {
    match client.download(downloadable, whatsapp_rust::download::DownloadLimits::default()).await {
        Ok(data) => Ok(data),
        Err(error) => {
            match &error {
                ClientDownloadError::ReferenceRejected(_) => eprintln!("Media reference rejected"),
                ClientDownloadError::Preparation(_) => eprintln!("Invalid media metadata"),
                _ => eprintln!("Download failed: {error:?}"),
            }
            Err(error)
        }
    }
}

Download errors redact opaque backend text in Display and Debug. Match typed variants instead of parsing diagnostic strings. Explicit access to the source chain can expose signed URLs; see safe diagnostics.

Upload Errors

async fn safe_upload(
    client: &Client,
    data: Vec<u8>,
    media_type: MediaType,
) -> Result<UploadResponse> {
    match client.upload(data, media_type, Default::default()).await {
        Ok(upload) => {
            println!("✅ Uploaded to: {}", upload.url);
            Ok(upload)
        }
        Err(e) => {
            eprintln!("Upload failed"); // The returned source may contain signed URLs.
            Err(e)
        }
    }
}

Advanced Usage

Custom media processing

use image::DynamicImage;

// Download and process image
if let Some(img) = message.image_message.as_option() {
    let data = client.download(img, whatsapp_rust::download::DownloadLimits::default()).await?;
    
    // Load with image crate
    let image = image::load_from_memory(&data)?;
    
    // Resize
    let thumbnail = image.resize(200, 200, image::imageops::FilterType::Lanczos3);
    
    // Save
    thumbnail.save("thumbnail.jpg")?;
}

Streaming with Progress

When you pass a writer to download_to_writer, you must implement DownloadWriter, not just Write + Seek — see that reference for why. For a wrapper like this one, the impl is a one-line delegation to the inner writer, plus resetting your own tracked state to match:

use std::fs::File;
use std::io::{Write, Seek};
use std::sync::{Arc, Mutex};
use whatsapp_rust::wacore::download::DownloadWriter;

struct ProgressWriter<W> {
    inner: W,
    total: Arc<Mutex<usize>>,
}

impl<W: Write> Write for ProgressWriter<W> {
    fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
        let n = self.inner.write(buf)?;
        *self.total.lock().unwrap() += n;
        println!("Downloaded {} bytes", *self.total.lock().unwrap());
        Ok(n)
    }
    
    fn flush(&mut self) -> std::io::Result<()> {
        self.inner.flush()
    }
}

impl<W: Seek> Seek for ProgressWriter<W> {
    fn seek(&mut self, pos: std::io::SeekFrom) -> std::io::Result<u64> {
        self.inner.seek(pos)
    }
}

impl<W: DownloadWriter> DownloadWriter for ProgressWriter<W> {
    fn truncate(&mut self, len: u64) -> std::io::Result<()> {
        self.inner.truncate(len)?;
        // download_to_writer truncates to 0 at the start of every attempt
        // (including retries after a failed host), so the counter has to
        // follow along or it double-counts bytes from an attempt that failed.
        *self.total.lock().unwrap() = len as usize;
        Ok(())
    }
}

let file = File::create("video.mp4")?;
let progress_writer = ProgressWriter {
    inner: file,
    total: Arc::new(Mutex::new(0)),
};

let _file = client.download_to_writer(video, progress_writer, whatsapp_rust::download::DownloadLimits::default()).await?;

Automatic retry and failover

For session-derived download routes, HTTP 401 can trigger one media-session refresh and URL re-derivation with refreshed hosts. HTTP 403/404/410 are terminal reference rejections; refreshing hosts cannot renew a signed reference. Download routes carry no auth token. Static URLs bypass session refresh, and MediaDownloader returns a reference rejection immediately because it has no session. Transport, HTTP, or integrity failures can fall over to another host. Local writer failures are terminal. Inspect the typed download errors and publish the destination only after success; cleanup after cancellation is not guaranteed. Upload retains its authentication token and credential-refresh behavior. See upload for that separate path.

Additional retry logic

For transient errors beyond reference rejections, you can implement your own retry wrapper:

use tokio::time::{sleep, Duration};
use whatsapp_rust::{Client, download::{ClientDownloadError, Downloadable}};

async fn download_with_retry(
    client: &Client,
    downloadable: &dyn Downloadable,
    max_retries: u32,
) -> Result<Vec<u8>, ClientDownloadError> {
    let mut attempt = 0;
    loop {
        match client.download(downloadable, whatsapp_rust::download::DownloadLimits::default()).await {
            Ok(data) => return Ok(data),
            Err(e @ ClientDownloadError::HostsUnreachable(_)) if attempt < max_retries => {
                attempt += 1;
                eprintln!("Retry {}/{}: {:?}", attempt, max_retries, e);
                sleep(Duration::from_secs(2u64.pow(attempt))).await;
            }
            Err(e) => return Err(e),
        }
    }
}

Media connection

Automatic management

The client caches media connection information. Downloads use its CDN hosts; uploads also use its authentication token. Session-derived downloads can refresh hosts once after HTTP 401. HTTP 403/404/410 are terminal for downloads, while uploads refresh credentials on 401/403:

// Each operation applies its own refresh policy
let upload = client.upload(data, MediaType::Image, Default::default()).await?;
let download = client.download(downloadable, whatsapp_rust::download::DownloadLimits::default()).await?;

// The client manages the cached media connection.

Host types and failover order

Each media connection includes multiple CDN hosts with a host_type field indicating whether the host is "primary" or "fallback". The client sorts hosts with primary hosts first, so uploads and downloads always try the fastest hosts before falling back to alternatives. Each host may also include a fallback_hostname for additional resilience.

Cache expiration

Media connections have two TTL values:

ttl — how long the route/host information is valid
auth_ttl — how long the auth token specifically is valid (may be shorter than ttl)

The client uses the minimum of these two values to determine when the cached connection has expired. When expired, the next session-derived media operation fetches fresh connection information. Download routes retain only its hosts.

Internal refresh

Media connection refresh and invalidation are managed internally by the client. Download refresh updates hosts and re-derives the URL without adding an auth token. Static download URLs bypass session refresh, and standalone MediaDownloader has no session to refresh. Upload credential refresh remains separate.

Best Practices

Next Steps

Sending Messages - Send media with captions and quotes
Receiving Messages - Handle incoming media
Custom Backends - Implement custom HTTP clients for media operations

​Overview

​Downloading Media

​From message objects

​Streaming Download

​From raw parameters

​Streaming from raw parameters

​Downloading without an active session

​Thumbnails

​Setting thumbnails on media messages

​Thumbnail fields by message type

​Reusing thumbnails from incoming messages

​Downloading link thumbnails

​Forwarding media via CDN reuse

​When CDN reuse won’t work

​Uploading Media

​Basic Upload

​Using upload response in messages

​Sending media as an album

​Resumable uploads

​Media Types

​Available media types

​Media type properties

​Encryption Details

​Upload Encryption

​Chunk-based encryption with MediaEncryptor

​Streaming encryption from a reader

​Download Decryption

​Error Handling

​Download Errors

​Upload Errors

​Advanced Usage

​Custom media processing

​Streaming with Progress

​Automatic retry and failover

​Additional retry logic

​Media connection

​Automatic management

​Host types and failover order

​Cache expiration

​Internal refresh

​Best Practices

​Next Steps

Overview

Downloading Media

From message objects

Streaming Download

From raw parameters

Streaming from raw parameters

Downloading without an active session

Thumbnails

Setting thumbnails on media messages

Thumbnail fields by message type

Reusing thumbnails from incoming messages

Downloading link thumbnails

Forwarding media via CDN reuse

When CDN reuse won’t work

Uploading Media

Basic Upload

Using upload response in messages

Sending media as an album

Resumable uploads

Media Types

Available media types

Media type properties

Encryption Details

Upload Encryption

Chunk-based encryption with MediaEncryptor

Streaming encryption from a reader

Download Decryption

Error Handling

Download Errors

Upload Errors

Advanced Usage

Custom media processing

Streaming with Progress

Automatic retry and failover

Additional retry logic

Media connection

Automatic management

Host types and failover order

Cache expiration

Internal refresh

Best Practices

Next Steps