Media Asset

A media asset is a reusable creative - a display image, native ad, TV video, billboard design, or audio file - kept in the advertiser's library. Where an ad lives inside a single campaign, a media asset acts as a template you can reuse across many. Building an ad from a media asset captures its current state, so later edits to the asset don't change ads that already shipped.

API operations

Relationships

Media assets serve as templates for ads. Creating an ad from an asset captures a snapshot of the asset's properties; later changes to the asset do not propagate to that ad.
Media assets are never directly assigned to campaigns. They are connected to campaigns only through ads derived from them.
Ads retain a soft reference to their source asset, so performance can be aggregated across every ad derived from a single media asset.

Key concepts

Snapshot
When an ad is created from a media asset, the ad captures the asset's content at that moment. Subsequent changes to the media asset (e.g., updated destination URL or tags) do not propagate to existing ads.
Soft Reference
An ad records which media asset it was derived from, but the ad is otherwise an independent entity owned by its campaign.
Auto Creation
When creating an ad from a media asset, the system auto-populates ad fields from the asset (name, image/video data, destination URL, dimensions). Only campaignId is required, and an optional name overrides the default.

Constraints

Rules to follow
  • Display assets are compatible with internet campaigns only.
  • Billboard assets are compatible with billboard campaigns only.
  • TV assets are compatible with connected TV campaigns only.
  • Native assets are compatible with internet campaigns only and require both an image upload and all text metadata fields.
  • Native asset uploads are limited to 5MB and must be image/png, image/jpeg, or image/gif.
  • Audio assets are compatible with audio campaigns only and accept MP3, WAV, or MP4/M4A files up to 5MB.

Request format - multipart vs JSON

Operations marked with the orange UPLOAD badge are HTTP POSTs whose request body is encoded as multipart/form-data rather than JSON, so they can carry a binary file alongside the form fields. Sending a JSON body with a base64-encoded file or a URL in place of the binary will be rejected.

Each upload endpoint expects a single file field with the binary content, plus the other form fields (name, destinationUrl, native text fields, etc.) as part of the same multipart body. From the command line use curl -F "file=@..."; from a browser or Node client, build a FormData object and pass it as the fetch body. Do not manually set the Content-Type header - the runtime sets it automatically with the correct multipart boundary, and overriding it strips the boundary and breaks the upload. The MIME type of the file is detected from the file's bytes, not from the filename.

fetch + FormData
const form = new FormData();
form.append("file", fileBlob, "spot.mp3");
form.append("name", "Brand audio spot");
form.append("clickUrl", "https://example.com");

await fetch(`https://api.adcritter.com/v1/advertisers/${advertiserId}/media-assets/audio`, {
  method: "POST",
  headers: { "X-Api-Key": process.env.ADCRITTER_KEY },
  body: form,
});

The non-upload operations - list, get, update, delete, and create-ad-from-media-asset - use a normal JSON request body (or no body at all), so the multipart concern only applies to the file uploads.

When building apps

Reusable Creative Shelf
Treat the media library as a creative shelf: upload each finished creative once with the matching type-specific endpoint, then call create-ad-from-media-asset to spin up campaign-bound ads on demand instead of re-uploading the file. Use list and get to power library browsing, update for metadata edits (name, destination URL, tags), and delete to retire unused assets - existing ads keep their snapshot. To compare the same creative across campaigns or audiences, group reporting by source media asset.