Access Status
Request the complete endpoint reference during scoped onboarding. It includes tenant-specific domains, auth behavior, entitlement rules, media provider configuration, billing provider behavior, and deployment-specific client contracts. Use this page to understand client API shape, app responsibilities, and integration boundaries when planning web, mobile, and TV delivery.
Contract Model
Organize client APIs around how streaming apps run: bootstrap the app, discover catalog content, establish viewer identity, evaluate access, start playback, then sync activity back to the platform.
| Area | Includes |
|---|---|
| Application boot | Brand settings, feature flags, navigation, legal links, app version rules, and public configuration. |
| Catalog discovery | Home rows, pages, carousels, search, genres, collections, content detail, seasons, episodes, and related titles. |
| Viewer identity | Login, registration, profile selection, session refresh, device identity, account settings, and logout behavior. |
| Playback access | Entitlement checks, signed stream responses, subtitle and audio tracks, watch progress, continue watching, and provider status. |
| Commerce | Plan selection, subscription state, PPV purchases, rentals, activation codes, discounts, invoices, and app-store billing state. |
| Engagement | Watchlist, likes, comments, notifications, support tickets, and localized messaging for client surfaces. |
Authentication
Separate account identity from viewing profile context. Preserve both when moving between discovery, playback, and account screens.
- 1Start with app contextLoad public app configuration before requesting authenticated resources.
- 2Resolve account sessionHandle login, token refresh, logout, and device identity before profile-specific calls.
- 3Select viewer profileAdd maturity, language, watch-state, and personalization context to catalog and playback requests.
- 4Refresh safelyRetry expired sessions through the configured refresh path, then fall back to a signed-out route if refresh fails.
Catalog APIs
Request catalog responses designed for app rendering. Cards include presentation fields for rows and grids; detail responses include seasons, episodes, trailers, cast, entitlement labels, canonical images, and provider readiness.
Playback APIs
Start playback with an entitlement decision, not a raw video URL. Evaluate content status, account state, selected profile, device rules, access type, purchase history, subscription state, maturity rules, and provider readiness before returning a playable response.
| State | Meaning |
|---|---|
| Allowed | The response includes a signed playback reference, track metadata, progress state, and reporting endpoints. |
| Requires subscription | The app receives the plan or offer context needed to route the viewer into the correct purchase flow. |
| Requires purchase or rental | The app receives the PPV/rental option, price label, availability window, and entitlement explanation. |
| Blocked | The API returns a localized reason such as unavailable region, inactive content, maturity restriction, device limit, or provider processing state. |
Commerce APIs
Support subscription, Free, PPV, rental, activation-code, discount, referral, and app-store flows. Rely on API-provided access labels and checkout instructions rather than hard-coding plan assumptions inside the app.
For hosted checkout providers, use the redirect or session state returned by the API. For mobile and TV surfaces, reconcile platform purchase state with the account record so entitlement decisions stay consistent across devices.
Errors & Limits
Map errors to product states. Route blocked playback, expired sessions, unavailable titles, or exhausted device limits to clear interface states instead of generic failure screens.
| Code | Meaning |
|---|---|
| 400 | The request shape is invalid or missing required client context. |
| 401 | The viewer session is missing, expired, or not refreshable. |
| 403 | The viewer is known but not entitled to the requested operation. |
| 404 | The content, page, profile, or commerce record is not available to the requesting surface. |
| 409 | The operation conflicts with current state, such as duplicate profile names or already-used activation codes. |
| 429 | The client crossed a rate or abuse boundary and should back off before retrying. |
Implementation Handoff
During onboarding, BitByte3 provides the scoped endpoint reference, environment URLs, authentication rules, provider configuration, required headers, response examples, error handling notes, and app-surface expectations.
- 1Map surfacesConfirm whether the project includes web, iOS, Android, Android TV, Apple TV, or custom frontend surfaces.
- 2Confirm providersLock media, billing, messaging, analytics, and metadata services before wiring client contracts.
- 3Validate critical flowsTest sign-in, profile selection, catalog discovery, purchase, playback, progress sync, and account recovery before launch.
Implementation Scope
Available references include app initialization, public catalog, authenticated account routes, profile sessions, playback access, subscription flows, notification settings, support flows, and operational error handling. Project documentation includes exact request and response contracts for the approved implementation team.
Request Access
To request API access, share target app surfaces, expected launch region, billing model, media provider, and whether the client app will be built by BitByte3 or your internal engineering team. Implementation teams receive the API reference during scoping, along with environment rules, auth strategy, webhook configuration, and client integration notes.