Mock sample for your project: ART19 Content API Documentation

Integrate with "ART19 Content API Documentation" from art19.com in no time with Mockoon's ready to use mock sample

ART19 Content API Documentation

art19.com

Version: 1.0.0


Use this API in your project

Speed up your application development by using "ART19 Content API Documentation" ready-to-use mock sample. Mocking this API will allow you to start working in no time. No more accounts to create, API keys to provision, accesses to configure, unplanned downtime, just work.
It also improves your integration tests' quality and reliability by accounting for random failures, slow response time, etc.

Description

The ART19 Content API conforms to the JSON:API specification.
API requests MUST use the HTTP Accept header:
Accept: application/vnd.api+json
API requests MUST be authenticated using the HTTP Authorization header:
Authorization: Token token="your-token", credential="your-credential"
General Notes
Some query parameters use unencoded [ and ] characters simply for readability. Defaults, examples, and
possible values are additionally rendered in double quotes for readability. In practice, query parameters should
not have quotes around the values (e.g., foo=bar is valid, not foo="bar"), and both query parameter keys
and values must be percent-encoded, per the requirements in RFC 3986 § 3.4.
Rate Limiting
In order to provide a fair distribution of available resources, all API calls are subject to rate limits.
If you exceed the number of API calls per minute granted to your credential, a 429 Too Many Requests
error response will be returned.
In that case, a Retry-After header MAY be included in the response, describing the number of seconds
after which a request can be retried.
If you run into a high number of 429 errors, please reach out to ART19 Support to adjust your rate limit.
Example
In the following example the request can be retried after waiting for 21 seconds:
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 21
Pagination
Requests to collection endpoints SHOULD provide pagination parameters.
Some endpoints REQUIRE pagination parameters to be provided.
Whenever pagination is provided, it MUST be valid.
Failing to provide pagination when it is required or providing wrong or incomplete pagination
always results in a 400 Bad Request error response.
The page numbering starts with 1 and the maximum page size (if not otherwise documented
on an endpoint) is 100. Pagination MUST NOT be specified if requesting a list of IDs (using an ids[] parameter).
Providing invalid values for page number or page size, as well as providing only a page number or only a page size,
is considered an error. Pagination is provided like this:
page[number]=1&page[size]=25
Responses conform to the JSON:API specification's pagination section
by including pagination links. Your requested page size will be carried into the pagination links.
Sorting
Requests to collection endpoints usually accept a sort parameter. Please refer to the
JSON:API Specification's sorting section for further details.
Relationship Linking
Currently, resources return all of their relationships, in no particular order, pursuant to how relationships
should be returned according to the JSON:API specification. Consumers of this API
MUST NOT make assumptions about the order of these collections. Even though this data is not currently paginated, consumers MUST support
paginating relationships per the JSON:API specification if this data is important for their application.

Other APIs in the same category

Semantic API

The Semantic API complements the Articles API. With the Semantic API, you get access to the long list of people, places, organizations and other locations, entities and descriptors that make up the controlled vocabulary used as metadata by The New York Times (sometimes referred to as Times Tags and used for Times Topics pages).
The Semantic API uses concepts which are, by definition, terms in The New York Times controlled vocabulary. Like the way facets are used in the Articles API, concepts are a good way to uncover articles of interest in The New York Times archive, and at the same time, limit the scope and number of those articles. The Semantic API maps to external semantic data resources, in a fashion consistent with the idea of linked data. The Semantic API also provides combination and relationship information to other, similar concepts in The New York Times controlled vocabulary.

Movie Reviews API

With the Movie Reviews API, you can search New York Times movie reviews by keyword and get lists of NYT Critics' Picks.

SYNQ Video

synq.fm
Sign up for a developer API key!
SYNQ API Guide

TV API

pressassociation.io
Welcome to the API Reference Docs page for the Press Association TV API (v2).
Webcomic of romance, sarcasm, math, and language.

Wowza Streaming Cloud REST API Reference Documentation

About the REST API
The Wowza Streaming Cloud TM REST API (application programming interface) offers complete programmatic control over live streams, transcoders, stream sources, and stream targets. Anything you can do in the Wowza Streaming Cloud UI can also be achieved by making HTTP-based requests to cloud-based servers through the REST API.
The Wowza Streaming Cloud REST API features cross-origin resource sharing, or CORS.
CORS is a W3C specification that provides headers in HTTP requests to enable a web server to safely make a network request to another domain.
In order to protect shared resources, the Wowza Streaming Cloud REST API is subject to limits. For details, see Wowza Streaming Cloud REST API limits.
About this documentation
This reference documentation is based on the open-source Swagger framework.
It allows you to view the operations, parameters, and request and reponse schemas for every resource. Request samples are presented in cURL (Shell) and JavaScript; some samples also include just the JSON object. Response samples are all JSON.
For more information and examples on using the Wowza Streaming Cloud REST API, see our library of Wowza Streaming Cloud REST API technical articles.
Query requirements
The Wowza Streaming Cloud REST API uses HTTP requests to retrieve data from cloud-based servers. Requests must contain proper JSON, two authentication keys, and the correct version number in the base path.
JSON
The Wowza Streaming Cloud REST API uses the JSON API specification to request and return data. This means requests must include the header Content-Type: application/json and must include a single resource object in JSON format as primary data.
Responses include HTTP status codes that indicate whether the query was successful. If there was an error, a description explains the problem so that you can fix it and try again.
Authentication
Requests to the Wowza Streaming Cloud REST API must be authenticated with two keys: an API key and an access key. Each key is a 64-character alphanumeric string that you can find on the API Access page in Wowza Streaming Cloud.
Use the wsc-api-key and wsc-access-key headers to authenticate requests, like this (in cURL):

Search Console API

View Google Search Console data for your verified sites.

BeyondCorp API

Beyondcorp Enterprise provides identity and context aware access controls for enterprise resources and enables zero-trust access. Using the Beyondcorp Enterprise APIs, enterprises can set up multi-cloud and on-prem connectivity solutions.

versionhistory.googleapis.com API

Version History API - Prod

Jellyfin API

jellyfin.local

MetaPub

prss.org
MetaPub collects, normalizes and distributes publicly available program, episode, and piece metadata through the public radio system. Backed by ContentDepot and its data model, MetaPub allows producers to supply metadata through various methods:
MetaPub Agents that collect producer metadata by "crawling" existing public feeds (e.g. C24, BBC) or the producer's production system (e.g. ATC, ME, TED Radio Hour).
Manually enter metadata in the ContentDepot Portal on each program and episode.
Publish/push the metadata to the MetaPub upload API and execute an ingest job.
MetaPub then distributes this data to stations through an electronic program guide (EPG model)
for display on various listener devices such as smart phones, tablets, web streams, HD radios, RDBS enabled FM radios, and more. The EPG format is based on the RadioDNS specifications.
RadioDNS and MetaPub
The RadioDNS Service and Programme Information Specification (TS 102 818 v3.1.1) defines three primary documents: Service Information, Program Information, and Group Information. These documents, along with the core RadioDNS Hybrid Lookup for Radio Services Specification (TS 103 270 v1.2.1) define a system where an end listener device can dynamically discover program metadata and fetch the metadata via Internet Protocol (IP) requests. MetaPub's use of RadioDNS differs slightly in that MetaPub (a.k.a PRSS) acts as the "service provider" while the stations and related middleware act as the end devices. While this is not the primary use case of RadioDNS, the flexibility in the specification, service definitions, and DNS resolution allows this model to be easily represented.
This documentation gives a high level overview of how the RadioDNS specifications will be used by MetaPub, however it is strongly recommended that the related RadioDNS specifications be read for implementation details, definitions, and required XML schemas.
ContentDepot Drive
ContentDepot Drive (CD Drive) provides a private, per customer file storage solution similar to other cloud storage solutions such as Google Drive, Box, and Dropbox. The CD Drive is used to stage content uploads such as metadata files, images, or segment audio before associating the content with specific programs or episodes.
CD Drive content can be referenced using a URI by some operations such as synchronizing metadata. There are two possible CD Drive URI formats supported: ID and hierarchical path. The ID reference takes the form . More information about URIs can be found at Wikipedia.
Authentication
The API currently uses OAuth 2.0. Some operations require specific scopes to limit clients while the ContentDepot backend may also enforce existing user specific permissions.

Geographic API

The Geographic API extends the Semantic API, using a linked data approach to enhance location concepts used in The New York Times' controlled vocabulary and data resources which combine them with the GeoNames database, an authoritative and free to use database of global geographical places, names and features.