Build more.
Manage less.
The Pustya Media API provides a unified interface for organizing media assets, automating processing tasks, and integrating content workflows into your applications.
Read the quick start →https://api.pustya.com/v1
One API. Multiple workflows.
A consistent interface for building media-oriented applications.
Media assets
Organize and retrieve asset metadata using structured resource identifiers.
Processing jobs
Submit asynchronous tasks and track their lifecycle through predictable states.
Integrations
Use standard HTTP methods and JSON payloads across different development environments.
Authentication
Protected API operations use bearer tokens. Clients include an access token in the HTTP Authorization header. Keep credentials on the server side and never expose them in public repositories or client-side code.
Authorization: Bearer YOUR_API_KEY Accept: application/json Content-Type: application/json
Quick start
The following examples illustrate the request structure for retrieving asset metadata and submitting media tasks.
# Retrieve media assets
curl -X GET \
"https://api.pustya.com/v1/assets" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Accept: application/json"
{
"data": [
{
"id": "asset_8e21",
"name": "sample-video.mp4",
"type": "video/mp4",
"status": "ready"
}
],
"pagination": {
"total": 1,
"has_more": false
}
}
API endpoints
Reference routes for asset management and processing workflows.
/v1/assets
Retrieve a paginated list of media assets.
/v1/assets/{id}
Retrieve metadata for a specific asset.
/v1/jobs
Submit a new asynchronous processing task.
/v1/jobs/{id}
Retrieve the current status of a processing task.
Response format
Successful requests return structured JSON objects. Processing operations may return a job identifier that can be used to retrieve subsequent status updates.
{
"data": {
"id": "job_7f42",
"operation": "transcode",
"state": "queued",
"progress": 0
}
}
Jobs may transition through queued, processing, completed, and failed states.
HTTP status codes
Standard HTTP codes are used to describe request outcomes.
| Code | Meaning |
|---|---|
| 200 | Request completed successfully |
| 201 | Resource created |
| 400 | Invalid request parameters |
| 401 | Authentication required |
| 403 | Insufficient permissions |
| 404 | Resource not found |
| 422 | Validation failed |
| 429 | Too many requests |
| 500 | Internal server error |
API versioning
API versions are identified by a version prefix in the request path. This allows clients to target a specific interface contract when integrating with the platform.
/v1/