TVOD Sales Dataset API - Prime Video Tech Docs

TVOD Sales Dataset API

Last updated 2026-08-17

The TVOD Sales Dataset provides transaction-level sales data for your Prime Video transactional video on demand (TVOD) business. Each record represents a completed transaction (purchase or rental). The data is delivered as an append-only changelog via the Slate Datasets API, giving you complete flexibility to build custom analytics and calculate metrics tailored to your business needs.

Key Benefits

  • Faster Insights — Sales data is batched multiple times per day, with most transactions delivered within ~9 hours of completion.
  • Cost and Sales Separation — Sales signals arrive in 4-hour batches; costing information (net_cogs) refreshes daily, so you get revenue signals as fast as possible.
  • Consistency — Standardized formatting across all territories in a single source.
  • Simplified Ingestion — Append-only changelog model with a simple upsert pattern for hands-off, automated ingestion.
  • Transaction-Level Granularity — Access individual order-level data to power custom analytics, title-level performance tracking, and internal system integrations.
  • Flexible Integration — Integrate TVOD sales data with your internal systems, data warehouses, and BI tools.

Feature

Slate Datasets API

Access Type

Programmatic (REST API)

Best For

Automated pipelines, enterprise reporting, custom analytics

Authentication

Login with Amazon (LWA) Security Profile

Data Format

CSV files (gzip compressed)


Getting Started

Prerequisites

  • Active Prime Video TVOD partnership
  • A login with Amazon (LWA) Security Profile
  • Client ID registered with your Content Account Manager (CAM)
  • An authorization code to request a token
  • A valid LWA authentication token for all API requests

Authentication Setup
To retrieve datasets you need to onboard to the Datasets API suite first. More details can be found here.

API Endpoints

Discovery Endpoints
Use these endpoints to look up your account and contract IDs programmatically:

Endpoint

Returns

GET /v2/accounts

List of Slate accounts you can access

GET /v2/accounts/{ACADIA_ID}

Business lines available (e.g., channels, transactions)

GET /v2/accounts/{ACADIA_ID}/transactions

List of TVOD contract IDs under your account

GET /v2/accounts/{ACADIA_ID}/transactions/{CONTRACT_ID}/datasets

Available datasets for a contract

Retrieving Dataset Files
Use this endpoint to retrieve links to transaction dataset files for your contract:

Request Parameters

Parameter

Description

ACADIA_ID

Your Slate account ID. Find it using GET /v2/accounts.

CONTRACT_ID

Your TVOD contract ID.

startDateTime

Set to the last time you pulled. Format: YYYY-MM-DDThh:mm:ssZ (UTC).

endDateTime

Set to current time. Format: YYYY-MM-DDThh:mm:ssZ (UTC).

limit

Maximum 1000 links per page.

This endpoint returns links to downloadable CSV files (gzip compressed) that contain the transaction logs — not the transactions directly.

Pagination
All responses are paginated. Use the following query parameters to navigate through results:

Parameter

Default

Description

limit

10

Number of documents returned per page. Maximum 1000.

offset

0

Number of pages to skip.

All paginated responses contain the following fields:

Field

Description

total

Total document count across all pages.

next

URL to the next page. Null if on the last page.

Data Model

Key Concepts

Concept

Description

Transaction

A completed order event (purchase or rental). Each transaction is identified by a unique order_item_id.

Changelog Model

Data is append-only. If a record’s attributes change (e.g., cost arrives), a new record is published with the same order_item_id but a newer last_update_time_utc.

Primary Key

order_item_id is the unique identifier for each transaction. Always deduplicate on this field.

Cost vs. Sales

Sales data arrives in 4-hour batches. Costing (net_cogs) refreshes daily, so records update with cost when available.

Data Freshness

Attribute

Target

Sales data delivery

Every 4 hours (batched)

Costing (net_cogs) refresh

Every 24 hours

End-to-end latency

~9 hours from transaction to data availability

Data retention

Maximum 2 years

Data Accuracy

Attribute

Details

Source of truth

Earnings and financial statements remain the final source of truth for payouts and costing.

Expected variance

Minor variance may exist due to date-time nuance and aggregation differences compared to financial/royalty reports.

Scope

Completed orders at the transaction grain for performance tracking. Not a replacement for financial or royalty reports.

This dataset is designed for faster, ongoing performance tracking. Expect minor variance compared to financial reports (e.g., Video ASIN Daily Level Summary) due to date-time nuance and aggregation differences. This is expected behavior, not a data quality issue.

Data Definitions

Core Fields
The following table describes all fields available in the transactions_event_log dataset:

Field Name

Type

Nullable

Description

Example

order_item_id

STRING

No

Unique identifier for each transaction. Primary key for deduplication.

ABC123XYZ

transaction_datetime_utc

TIMESTAMP

No

Transaction time in UTC.

2026-01-14T00:04:41.575

transaction_datetime_local

TIMESTAMP

No

Transaction time in local timezone.

2026-01-14T01:04:41.575

pv_title_id

STRING

No

Unique title identifier.

tt1234567

content_type

STRING

No

Type of content purchased.

Movie, TV Episode, TV Season

purchase_type

STRING

No

Purchase or rental indicator.

EST (purchase), VOD (rental)

content_quality

STRING

No

Video quality tier.

SD, HD, UHD

territory

STRING

No

Territory code.

US, GB, DE, JP, AU

device_class

STRING

Yes

Device category.

Fire TV, Mobile, Web

title_name

STRING

No

Title name.

The Great Adventure

currency

STRING

No

ISO 4217 currency code.

USD, EUR, JPY

vendor_sku

STRING

Yes

Partner-provided SKU.

WB-MOV-001

net_cogs

DECIMAL

Yes

Net cost of goods sold, excl. tax. Refreshes daily. May be NULL initially.

4.99

net_revenue

DECIMAL

No

Net revenue, excl. tax.

14.99

create_time_utc

TIMESTAMP

No

Record creation time in UTC.

2026-01-14T01:39:06.619

last_update_time_utc

TIMESTAMP

No

Record last update time. Used for deduplication logic.

2026-01-14T01:39:06.619

Field Notes
The following fields have important behavioral characteristics that partners should be aware of:

Field

Calculation / Logic

Notes

net_cogs

Refreshes daily

May initially appear as NULL or 0; updates within 24 hours when costing arrives.

last_update_time_utc

Latest timestamp wins

When multiple records exist for the same order_item_id, keep only the record with the latest last_update_time_utc.

territory

Single dataset for all territories

No per-territory files; filter by territory code as needed.

purchase_type

Fixed enum values

EST = Electronic Sell-Through (permanent purchase). VOD = time-limited rental.

Deduplication

Overview
The dataset uses a changelog model. When a record is updated (e.g., costing arrives), a new version is published with the same order_item_id and a newer last_update_time_utc. To maintain accurate data, always apply deduplication logic before writing records to your destination.

Deduplication Query
Use the following SQL pattern to deduplicate and retain only the latest version of each transaction:

Upsert Pattern
Use this pattern to maintain a local table with the latest state of every transaction:

ETL Pipeline

Overview
Follow this four-step process to build a reliable, automated ingestion pipeline for TVOD sales data.

Pipeline Steps

  1. Initial Data Pull — Pull all files for your contract within the desired time range using the API endpoint. Download all files returned. Each file contains transaction records in CSV format (gzip compressed).
  2. Deduplication — When multiple records exist for the same order_item_id while processing multiple days of data, keep only the latest last_update_time_utc record using the deduplication query in Section 6.2.
  3. Upsert to Destination — Merge deduplicated records into your destination table using order_item_id as the key. See the upsert pattern in Section 6.3.
  4. Incremental Processing — For ongoing data loads, set startDateTime to the last time you pulled and endDateTime to the current time. Process all returned files and upsert into your destination.

Set the following parameters for incremental runs:

Recommended Ingestion Cadence

Recommendation

Details

Recommended cadence

Every 4-6 hours to stay as current as possible.

Incremental processing strategy

Set startDateTime to the last retrieved timestamp and endDateTime to the current time. Process all returned files.

Daily/Weekly consumers

If you fetch daily or weekly, ensure you process all files for the full period to avoid missing records.

Recommended start time

For daily jobs, start at 1 AM UTC to capture prior day completions.

Sample Queries

Use these SQL patterns to get started with common analytics use cases. Replace [START_DATE], [END_DATE], and [X] with your desired values.

Top X Titles by Revenue Over a Period

Total Revenue by Purchase Type

Daily Sales Summary

Revenue by Territory

Quality Standards

Data Quality Targets

Quality Dimension

Target

Measurement

Completeness

>99% of transactions captured

Comparison against financial reports

Timeliness

~9 hours end-to-end latency

Time from transaction to data availability

Consistency

Single standardized format

All territories in one dataset

Known Limitations

Limitation

Description

Impact

Costing delay

net_cogs refreshes daily, not in real-time.

Records may initially show NULL or 0 cost; updates within 24 hours.

Data retention

Maximum 2 years of historical data.

Requests with timestamps older than 2 years will not return results.

Token expiration

LWA access tokens expire after 1 hour.

Must implement refresh token logic for uninterrupted access.

File-based delivery

API returns links to files, not direct data rows.

Requires a download step in your pipeline before processing.

Financial variance

Minor variance vs. financial/royalty reports.

Expected behavior due to date-time nuance; not a data quality issue.

Frequently Asked Questions

Can’t find what you’re looking for?

Contact us


Internal Server error! Please try again
Your session has expired

Please sign in to continue

Sign In
edit