Basic Request Structure

This page describes the basic request structure for calls to Broadsign Control API using REST.

For our example, we will use the method to list criteria that exist on our domain.

Copy 
curl -X GET "https://api-sandbox.broadsign.com:10889/rest/criteria/v8" -H "accept: application/json" -H "Authorization: Bearer YourAPIKeyHere"

 

Request Component Description
HTTP Verb In this example, we are using GET to list resources. We use the following verbs in our REST architecture:
  • HTTP GET: Used to list resources.
  • HTTP PUT: Used to update one resource.
  • HTTP POST: Used to create one resource.

For a list of all resources, see REST Method Reference.
End Point

Broadsign Control API Hostnames

Broadsign provides two endpoints (hostnames):

  • https://api-sandbox.broadsign.com: The sandbox endpoint, for testing your integration. See About the Sandbox (REST).
  • https://api.broadsign.com: The production endpoint.
10889 The port through which all API requests to Broadsign Server flow, whether on sandbox or production.
Resource Name In our example, the resource we want to list is criteria. This request will list all criteria on our domain. For a list of all resources, see REST Method Reference.
Resource Version Number In our example, the resource version number is v8. Resource version numbers increment independently from one another. So, the criteria resource is at v8 while our reservation (campaign) resource is at v12. Ensure that you are using the correct resource version number. See REST Method Reference.
Content Type Our REST architecture provides all responses in JSON. Set the type to application/json.
Authorization Broadsign accepts two types of authentication methods: HTTP Token or Public Key Fingerprint. In our example, we are using an HTTP Token. We recommend that you use the token for testing integration on your sandbox domain, and using the public key fingerprint on production. See Authentication (REST).