An ad is the creative shown to people when a campaign runs. Ads live inside a campaign and come in five formats - display, native, TV, billboard, and audio. Each format has a dedicated create endpoint that accepts a fresh upload, and any format can also be created from a saved media asset to reuse an existing creative.
API operations
Relationships
An ad belongs to exactly one campaign. Internet campaigns accept display ads, native campaigns accept native ads, TV campaigns accept TV ads, billboard campaigns accept billboard ads, and audio campaigns accept audio ads.
An ad is owned by an advertiser through its campaign association.
Media assets in the advertiser's asset library can be used as reusable templates for creating ads. Any ad format can be created directly from an upload or from an existing media asset.
Statuses
pending
Ad is awaiting approval before it can serve.
live
Ad is approved and eligible to serve.
disapproved
Ad was rejected during review and cannot serve.
inactive
Ad is no longer serving but has not been deleted.
deleted
Ad has been deleted.
Ad formats
Display ads are banner images. Native ads pair an image with a headline, body, company name, and call-to-action so the ad blends with publisher content. TV ads are video spots uploaded directly as files. Billboard ads are pre-designed images for digital out-of-home placements. Audio ads are short audio spots for streaming inventory. Each format has a dedicated create endpoint under /v1/advertisers/{advertiserId}/ads that accepts multipart/form-data with a binary file field. Display, native, billboard, and TV uploads cap at 5MB; audio uploads accept MP3, WAV, and MP4/M4A.
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 create endpoint expects a single file field containing the binary upload, plus the other form fields (campaignId, name, 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 itself is detected from the file's bytes, not from the filename.
The other ad 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 direct file uploads.
Reusing creatives via the media library
Any ad format can also be created from an existing media asset instead of a fresh upload. Upload the file once with the matching POST /v1/advertisers/{advertiserId}/media-assets/{type} endpoint, then call POST /v1/advertisers/{advertiserId}/media-assets/{mediaAssetId}/ads (create-ad-from-media-asset) with the destination campaignId to snapshot the asset onto the campaign. This is the right path when the same creative will run on multiple campaigns - the media asset stays in the library, and each ad is an independent snapshot of it. See the Media Asset entity for the upload and create-ad-from-media-asset operations.
When building apps
*Server-Side Upload Proxy
Route ad creates through a server-side proxy so the multipart upload - and the API key - never touches the browser. Match the campaign type to the ad format before posting: internet campaigns accept display ads, native campaigns accept native ads, TV campaigns accept TV ads, billboard campaigns accept billboard ads, and audio campaigns accept audio ads. For reusable creatives - and always for audio - upload to the media-asset library first and call create-ad-from-media-asset instead of re-uploading the file for each campaign.