Core API Reference

The CarrierX service offers a RESTful API that can be used to rent phone numbers, enable SMS for applications, support SIP trunking, and provision full-featured application endpoints.

Using the REST API

This section describes how to obtain credentials to use the API, what types of requests the system recognizes, and the format of the responses. It also holds reference information about pagination, filtering, and callbacks.

Using Postman

This documentation contains cURL commands that you will run in your terminal. Rather than use these commands, you can explore the API using Postman, a stand-alone client with a user-friendly interface. Postman is widely used for API development and allows you to test requests.

You will need to download the Postman client to your computer. To do so, visit the Postman website and click Download. Click Run in Postman to import this collection to the Postman app.

Main Conventions

The following conventions are used in the sections, which contain the tables with objects attributes, their types, and descriptions:

Authentication

The following curl command will return a list of all of the endpoints of the CarrierX account associated with the login credentials. Use your Core API token in the query below. The endpoint login and password values are listed in the returned JSON object.

curl -X GET \
'https://api.carrierx.com/core/v2/endpoints' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

The credentials of a specific endpoint are found in the properties attribute of the nested object. Locate the login and password values.

{
  "count": 1,
  "has_more": false,
  "items": [
      {
          "addresses": [],
          "attributes": {},
          "capacity": 0,
          "endpoint_sid": "844346ef-93e9-4fa8-a4ab-e3015af94573",
          "name": "flexml",
          "out_sip_password": null,
          "out_sip_username": null,
          "partner_sid": "ed437757-002d-4ecc-aa5a-efdf5e50dba0",
          "properties": {
              "account_sid": "1d4adc32-45d1-4789-9780-928049e2bce1",
              "api_url": "https://api.carrierx.com/flexml/v1",
              "container_sid": "null",
              "login": "sample_login",
              "password": "sample_password"
          },
          "transformations": [],
          "type": "flexml",
          "voip_token": null
      }
  ],
  "limit": 1000,
  "offset": 0,
  "pagination": {},
  "total": 1
}

All CarrierX API requests require authentication. The first step to using CarrierX API is obtaining a CarrierX account and gaining credentials. To do so, please submit a request through our Contact Us page.

Currently, CarrierX API requests use two types of authentication:

• Bearer token, used by the requests to the Core API.
• Basic HTTP authentication with login and password, used by the requests to the endpoint APIs (Conference, FlexML, and Mediator).

With the credentials you receive from CarrierX team, you can gain access to the Portal, where you will be able to create a security token. The security token allows you to work with the Core API and retrieve the endpoint login credentials for Conference, FlexML, and Mediator.

While the system allows request authentications for any users registered with CarrierX, the specific requests are limited by the scopes associated with the OAuth token that you use for the requests. This means that you might be eligible to make requests to CarrierX API, but not authorized to make a specific request, e.g., you can only view objects but not allowed to create, modify, or delete them.

You can create OAuth tokens with restricted access permissions (scopes) if you need that for a specific application. Refer to the Generate OAuth Bearer Token section for more details on this.

Prior to making requests to a Conference, FlexML, or Mediator endpoint, you need to create an application endpoint. Refer to the Configure an Application Endpoint quick start guide for step-by-step instructions on creating an endpoint.

Requests

Sample request to create Conference endpoint

curl -X POST \
'https://api.carrierx.com/core/v2/endpoints' \
-H 'Content-Type: application/json' \
--data-binary '{"name":"my_conf", "type":"conference"}' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

The requests in CarrierX API are made using the standard REST notation, typical for web services.

A simplest request will have the following structure:

• The request URL to which the request will be sent. The URL will be different for the Core API methods and for the main endpoint-related requests (conference, FlexML, mediator).
• The request method or the verb used for the REST over HTTP request.
• One or several headers or user/password authentication.
  • At least one header—-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'—is required to access the Core API.
  • For the requests to the conference, FlexML, or mediator endpoints, CarrierX uses the basic HTTP authentication with login and password (cURL -u option).

  Refer to the Authentication section for more details on this.

All the above elements are required for all CarrierX API requests.

Other request may have additional structure elements which include:

• Path arguments are required with some methods to access specific objects (GET the object by secure ID, PATCH/PUT, and DELETE objects).
• Body payload is required with POST and PATCH/PUT. Even if the object method does not require any body arguments (e.g., POST for some objects), the payload must still include an empty object (--data-binary '{}').
  
• Query arguments may be either optional or required for some requests. Refer to the objects sections below to see which object methods require the presence of the query arguments. The optional query arguments available with some GET requests include pagination, result filtering, and field filtering.
• Form data is required with some POST methods, e.g., uploading a file to the container using multipart/form-data content type.

Request URL

The usual path to the API objects includes the base URL to the API used with the object (Core API base URL for the objects used throughout the CarrierX products, or specific API base URLs used for FlexML, Mediator, or Conference), and the path to the object collections and the object items.

If the action targets the specific object, the path to it will include the object secure ID (SID), which allows to distinguish the targeted object from the other ones in the same collection.

The system only accepts HTTPS requests, and not HTTP requests.

Request Methods

CarrierX API uses five main verbs (methods) of REST over HTTP for the requests: POST, GET, PUT, PATCH, and DELETE. These methods are used to create the objects, get the information about the objects, modify the objects, and delete them.

CarrierX partners need to have special permissions (or scopes) to use API methods on various objects. Refer to the available_scopes table for the complete list of the scopes that define the partner’s permissions on objects and collections.

POST

Sample POST request that creates a trunk

curl -X POST \
'https://api.carrierx.com/core/v2/trunk_groups/138ed522-6633-405b-b58d-55eb0d262e32/trunks' \
-H 'Content-Type: application/json' \
--data-binary '{}' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

The POST method is used to create new objects. When you create a new object, you usually need to specify at least some of the attributes for the object to be created in the request payload.

The successful POST request will return a 200 response with the serialized JSON copy of the created object.

GET

Sample GET request that returns the currently logged-in partner

curl -X GET \
'https://api.carrierx.com/core/v2/oauth/whoami' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

The GET method is used to view the information about the existing objects and their collections.

Generic GET requests return the list of all the objects (or collections) available for the request sent. Most of such GET requests can be used together with Pagination, Result Filtering, and Field Filtering.

GET requests aimed at a specific object require to use the object secure ID to be included as a part of the request path, and return the information about the specified object only. Most of such GET requests can be used together with Field Filtering.

The successful GET request will return a 200 response with the serialized JSON copy of the requested objects (or specific object).

PATCH/PUT

Sample PATCH request that modifies or adds a new name record of the nested attributes object

curl -X PATCH \
'https://api.carrierx.com/core/v2/partners/aeda835c-6627-4f4c-ac73-9edcae95640b' \
-H 'Content-Type: application/json' \
--data-binary '{"attributes":{"name":"New Partner Name"}}' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response The serialized JSON copy of the created object together with the nested object

{
    "attributes": {
        "name": "New Partner Name"
    },
    ...,
    "partner_sid": "ed437757-001d-4ecc-aa5a-efdf5e50dba0"
}

Sample PATCH request that adds a new name2 record of the nested attributes object of the same Partner object

curl -X PATCH \
'https://api.carrierx.com/core/v2/partners/aeda835c-6627-4f4c-ac73-9edcae95640b' \
-H 'Content-Type: application/json' \
--data-binary '{"attributes":{"name2":"New Partner Name 2"}}' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response The serialized JSON copy of the created object together with the modified nested object

{
    "attributes": {
        "name": "New Partner Name"
        "name2": "New Partner Name 2"
    },
    ...,
    "partner_sid": "ed437757-001d-4ecc-aa5a-efdf5e50dba0"
}

Sample PATCH request that modifies the entire nested attributes object of the same Partner object

curl -X PATCH \
'https://api.carrierx.com/core/v2/partners/aeda835c-6627-4f4c-ac73-9edcae95640b?nested_objects=replace' \
-H 'Content-Type: application/json' \
--data-binary '{"attributes":{"name3":"New Partner Name 3"}}' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response The serialized JSON copy of the created object together with the nested object

{
    "attributes": {
        "name3": "New Partner Name 3"
    },
    ...,
    "partner_sid": "ed437757-001d-4ecc-aa5a-efdf5e50dba0"
}

The PATCH/PUT methods are both used to modify the existing objects and their attributes. The difference between them is explained below.

PATCH is used to modify only some of the object attributes and does not require to send the entire object in the request payload. Only the attributes and their values that need to be modified can be sent in the request body.

Objects can have a complex structure and can contain other objects as part of them, i.e., nested inside them. When you use PATCH and want to modify the nested objects, PATCH follows the below rules to define what must be updated and how:

1. If the existing nested object contains the same record (by key), the existing record will be replaced with the new value, provided in the PATCH request. The other nested object records will remain unmodified.

2. If the existing nested object does not contain the same record, a new record will be added to the object. The other nested object records will remain unmodified.

3. If the existing nested object contains the same record and the value of the incoming record is null, then the existing record will be removed. The other nested object records will remain unmodified.

4. If the PATCH request contains nested_objects=replace as a query attribute, the whole nested object will be replaced with a new one (i.e., all the old records and their values will be removed and only the new ones will be added).

PUT is used to modify the complete object and require to send the entire object (together with the nested objects, if there are any) in the request payload.

Both PATCH and PUT requests are aimed at a specific object and require the object secure ID as a part of the request path.

The successful PATCH/PUT request will return a 200 response with the serialized JSON copy of the modified object.

DELETE

Sample DELETE request that deletes an endpoint

curl -X DELETE \
'https://api.carrierx.com/core/v2/endpoints/1a34c5e9-3a09-4de5-b553-5f6a9ef202ac' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

The DELETE method is used to delete the object targeted by its secure ID.

The successful DELETE request will return a 204 response code with an empty body.

Rate Limiting

Currently, CarrierX applies no rate limiting to the partners requests to CarrierX API.

Responses

All responses return conventional HTTP status codes. Most of the responses (GET, POST, PATCH/PUT) also return objects in the JSON format.

CarrierX API allows cross-origin (CORS) requests and data transfers.

HTTP Status Codes

Typical 200 status code in the response

HTTP/2 200
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Access-Control-Allow-Origin,Access-Control-Allow-Methods,Access-Control-Allow-Credentials,Content-Disposition,Access-Control-Allow-Headers
Content-Length: 1333
Content-Type: application/json
Date: Wed, 22 Sep 2021 08:23:06 GMT
Server: nginx
Strict-Transport-Security: max-age=31536000; includeSubDomains
Vary: accept-encoding

The Core API uses the following HTTP status codes:

Sample 400 status code when the JSON sent in the request body has errors in its syntax:

{
    "body": {
        "message": "cannot parse json. Check json for validity",
        "errors": null
    },
    "status": 400
}

Sample 401 status code when trying to send a request without authentication:

{
  "message": "authentication required",
  "errors": [
    {
      "field": "cause",
      "message": "authentication required",
      "reference_sid": null
    }
  ]
}

Sample 403 status code when trying to access resources you do not have enough permission for:

{
    "message": "permission denied",
    "errors": [
        {
            "field": "cause",
            "message": "permission denied",
            "reference_sid": null
        }
    ]
}

Sample 404 status code when trying to access a non-existent object (e.g., a token with an incorrect SID):

{
    "message": "no item error",
    "errors": [
        {
            "field": null,
            "message": "cannot find token",
            "reference_sid": null
        }
    ]
}

Response Objects

Typical formatted JSON object in the response

{
    "callback_url": null,
    "did_group_sid": "41e21049-e5eb-433c-a93d-d57417b1863c",
    "name": "N/A",
    "partner_sid": "e00430c3-a7d0-4666-ab5c-f7202448382f"
}

Successful requests return objects in the JSON format with application/json set as Content-Type. The object keys and values depend on the request and the object returned, and are described in the corresponding object sections.

Normally, the system returns the object fields unordered and unformatted. To view the object fields ordered alphabetically and “pretty-formatted” in the response to the command-line requests (e.g., cURL), use the jq command-line JSON processor or similar tools.

With jq, the request will look like this:

curl -X GET 'https://api.carrierx.com/core/v2/oauth/whoami' -H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda' | jq -S

Pagination

This request returns Country objects sorting them descending by the common_name attritute, starting with the second record available, and returns a maximum of two records.

curl -X GET \
'https://api.carrierx.com/core/v2/countries?offset=2&limit=2&order=common_name+desc' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

To view records not included in the response, make a request to the URL value of the previous or the next key.

{
  "count": 2,
  "has_more": true,
  "items": [
    {
      "capital": "Sana'a",
      "common_name": "Yemen",
      "dialing_prefix": "967",
      "domain": "ye",
      "iso_3166_alpha_2": "YE",
      "iso_3166_alpha_3": "YEM",
      "iso_3166_numeric": 887,
      "mcc": "421",
      "official_name": "Republic of Yemen",
      "region": "Asia",
      "subregion": "Western Asia"
    },
    {
      "capital": "El Aaiún",
      "common_name": "Western Sahara",
      "dialing_prefix": null,
      "domain": "eh",
      "iso_3166_alpha_2": "EH",
      "iso_3166_alpha_3": "ESH",
      "iso_3166_numeric": 732,
      "mcc": null,
      "official_name": "Sahrawi Arab Democratic Republic",
      "region": "Africa",
      "subregion": "Northern Africa"
    }
  ],
  "limit": 2,
  "offset": 2,
  "pagination": {
    "next": "https://api.carrierx.com/core/v2/countries?limit=2&order=common_name+desc&offset=4",
    "previous": "https://api.carrierx.com/core/v2/countries?limit=2&order=common_name+desc&offset=0"
  },
  "total": 251
}

You can use the pagination to limit the number of the objects returned in the response and sort them by the object attributes.

The pagination is available for the GET requests which return the lists of the objects without targeting them by secure IDs.

The pagination parameters include:

limit

An integer parameter that determines how many items are returned in the response. The entered value cannot exceed 1000.

The default value is 10, meaning that a maximum of ten items will be returned.

order

A string parameter that allows to sort the returned objects. Three values are accepted for this parameter:

• attribute name + asc to sort the items in the response in the ascending or alphabetical order (default order).
• attribute name + desc to sort the items in the response in the descending or reverse-alphabetical order.
• shuffle to randomize the order of the items in the response.

offset

An integer parameter that determines the amount of items that are skipped in the response.

The default value is 0, meaning that the first existing item will appear first.

after/ before

This request returns a maximum of one record of SMS Detail Record objects following the object with the b6d574ea-b11f-41fd-a25f-602e7b28807f secure ID.

curl -X GET \
'https://api.carrierx.com/core/v2/sms/message_drs?after=b6d574ea-b11f-41fd-a25f-602e7b28807f&limit=1' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

To view records not included in the response, make a request to the URL value of the previous key.

{
    "count": 1,
    "has_more": true,
    "items": [
        {
            "date_insert": "2020-07-24T10:25:11.000Z",
            "date_sent": "2020-07-24T10:25:11.014Z",
            "date_start": "2020-07-24T10:25:11.014Z",
            "date_stop": "2020-07-24T10:25:12.014Z",
            "delay_sent": 0,
            "direction": "outbound",
            "dr_sid": "92cd9154-2f53-4e62-8b4e-8ff6e4849d16",
            "mcc": 310,
            "media_urls": [],
            "message": "This is a test message.",
            "message_segments": 1,
            "mnc": 999,
            "number_billing": "15162065870",
            "number_dst": "12078152557",
            "number_external": "12078152557",
            "number_src": "15162065870",
            "partner_sid": "8d180104-0b34-4e55-907f-4a72409484c9",
            "price": "0.005",
            "provider": "tsg",
            "rate": "0.005",
            "status": "sent",
            "type": "sms",
            "user_data": "test_message",
            "version": null
        }
    ],
    "limit": 1,
    "offset": 0,
    "pagination": {
        "previous": "https://api.carrierx.com/core/v2/sms/message_drs?before=92cd9154-2f53-4e62-8b4e-8ff6e4849d16&limit=1&offset=0"
    },
    "total": null
}

For some objects (e.g., Call Detail Record or SMS Detail Record objects), the system will not return their total number. This can happen as the number dynamically changes in large quantities and can become not relevant by the time of the next request.

In this case, instead of using the standard pagination offset (which is rather difficult to calculate as the system does not return the total number of objects), you can use the after or before query arguments. With these arguments, the system will return the objects which precede or follow the entered object secure ID. This might be useful if you want to receive an exact range of the objects and know the secure IDs of the records which start and end this range.

Currently, CarrierX supports the pagination that uses the after and before arguments for the following objects and methods:

Request Parameters Combinations

You can use the following combinations of the pagination parameters:

• limit, offset, order: https://api.carrierx.com/core/v2/countries?limit=2&offset=2&order=common_name+desc

• after, limit, order: https://api.carrierx.com/core/v2/calls/call_drs?after=bb2aacd2-23d3-418e-9ec0-2fc45c5f9d76&limit=1&order=date_stop+asc

• before, limit, order: https://api.carrierx.com/core/v2/calls/call_drs?before=56fb6b94-811e-4952-b242-4e06f4e95b7e&limit=1&order=date_stop+desc

• after, before, limit, order: https://api.carrierx.com/core/v2/sms/message_drs?after=012e1d6a-75ac-43ec-bacc-68f1ef1c60a3&before=b6d574ea-b11f-41fd-a25f-602e7b28807f&limit=100&order=date_insert+desc

If you omit any of the parameters from the response, their default values will be used (if there are any).

Pagination Response

The JSON response for a successful query using the pagination parameters will include the following attributes:

Result Filtering

This GET request returns Endpoint objects that meet the filter criteria. In this case, we are narrowing the results to the conference endpoint type.

curl -X GET \
'https://api.carrierx.com/core/v2/endpoints?filter=type+eq+conference' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

The following response includes all of the endpoints that fit the filter criteria.

{
    "count": 1,
    "has_more": false,
    "items": [
        {
            "addresses": [],
            "attributes": {},
            "capacity": 0,
            "endpoint_sid": "613325f8-bbb8-4599-b477-1b4fef3d017c",
            "name": "my_example_conference",
            "partner_sid": "6nelo9p3-3eef-4f75-8f48-fb98e99908be",
            "properties": {
                "account_sid": "bdrU77AFb-Y1sDwqqxkeb.M3LP7hSKYg",
                "api_url": "https://api.carrierx.com/conference/v1",
                "container_sid": "null",
                "login": "username",
                "password": "password"
            },
            "transformations": [],
            "type": "conference",
            "voip_token": null
        }
    ],
    "limit": 1000,
    "offset": 0,
    "pagination": {},
    "total": 1
}

The filter parameter is added to the query URL to restrict or customize the results of a JSON response by certain parameters (e.g., name, capabilities, state, country_code, etc.). The common rule is that, with some exceptions, you can filter those results by any top-level field(s) that are returned in the response. Moreover, in some cases you can use the nested subfields for result filtering. In this case you need to use a dot in the filter name to separate the parent field and the nested subfield, e.g. trunks.allow_transfer eq false or properties.login eq username.

The structure of result filtering is as follows: filter=object_attribute filter_operator value. You can also use the and operator to combine several filters for more specific searches. For example, for a DID object we could apply the following filter: filter=state eq "NY" and phonenumber like "%555%".

Filter values can also be put inside single or double quotes. This is not necessary when the filter value is just a single word like USA. However, if your filter value consists of more than one word, the quotes are required. For example, name eq "filter value name".

Result Filtering Quick Reference

Field Filtering

In the following, we request Endpoint objects without the properties field.

curl -X GET \
'https://api.carrierx.com/core/v2/endpoints?exclude_fields=properties' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

The following response excludes the properties field from returned Endpoint objects.

{
    "count": 1,
    "has_more": false,
    "items": [
        {
            "addresses": [],
            "attributes": {},
            "capacity": 0,
            "endpoint_sid": "613325f8-bbb8-4599-b477-1b4fef3d017c",
            "name": "my_example_conference",
            "out_sip_password": null,
            "out_sip_username": null,
            "partner_sid": "6nelo9p3-3eef-4f75-8f48-fb98e99908be",
            "transformations": [],
            "type": "conference",
            "voip_token": null
        }
    ],
    "limit": 1000,
    "offset": 0,
    "pagination": {},
    "total": 1
}

There are two parameters associated with field filtering: include_fields, and exclude_fields. By default, the fields included in JSON responses are specific to the request made. These returned fields are explained in the Object section for that object.

Refer to the specific object to determine which fields can be included and excluded from the JSON responses.

include_fields and exclude_fields accept comma-separated strings as values.

Field Filtering Quick Reference

Core Concepts

This section outlines core concepts having to do with the Core API.

Batch Operations

The Batch API allows you to create, update, and delete tasks. Tasks are bulk operations that modify one or more phonenumber, prefix or file. When you create a batch task, you will have the option to review the items if you set the review field to boolean true value. In this case, your returned JSON status will be pending_review.

If the changes look correct, you can make a PATCH or PUT request to change the status from pending_review to approved. If the items look incorrect, the batch request can be prevented from proceeding by changing the status to cancelled.

Callbacks

The CarrierX API enables callbacks to be sent to a URL. The callbacks are triggered when a specific action occurs, such as when either sending or receiving an SMS, calling into a conference, etc. The callback data will be the object that was affected. For example, if an SMS was sent to or from a phone number associated with a callback URL, the callback will be the SMS object.

Callbacks are assigned on either the DID object or the Partner object. If a callback URL is assigned on both the DID object level and the Partner object level, the DID object callback URL will override the Partner object callback URL.

On the Partner object, you can set the following callbacks

• for SMS activity use the sms field in the callbacks object;
• for the mediator endpoints activity use the app_mediator field;
• for the conference endpoints activity use the app_conference_call and app_conference_meeting fields.
• to get a callback confirming that a DID from an external provider has been rented successfully, use the phonenumber_order field.

On the DID object, set the value of the callback_url field for the callbacks related to SMS activity.

sms and callback_url Callback

The callback response. Refer to the SMS object for more information about each attribute and value.

{
    "date_changed":"2023-09-04T17:37:38.852Z",
    "date_created":"2023-09-04T17:37:36.123Z",
    "date_status_changed":"2023-09-04T17:37:00.000Z",
    "direction":"outbound",
    "from": "15162065319",
    "group_recipients":[],
    "mcc":250,
    "media_urls":[],
    "message": "This is a test inbound message delivered by CarrierX",
    "message_segments": 1,
    "message_sid": "e405fa47-48f5-4dc5-bbba-77231587188e",
    "mnc": null,
    "partner_sid": "QLJ79xlC2vP-UEx3hS0R4rldas8.G1UB",
    "price": "1",
    "status": "received",
    "to": "15162065318",
    "type":"sms",
    "user_data":null}
}

The system sends sms and callback_url callbacks when an action related to an SMS event occurs.

app_mediator Callback

The app_mediator callback response

{
    "attributes":{},
    "date_insert":"2019-01-25T18:12:10.770Z",
    "date_start":"2019-01-25T18:08:23.000Z",
    "date_stop":"2019-01-25T18:09:08.000Z",
    "date_talk":"2019-01-25T18:08:44.000Z",
    "direction":"inbound",
    "dr_sid":"2a217f8d-df41-4e3d-bece-c72eaa2a8e2a",
    "dtmf":null,
    "duration":45,
    "endpoint_sid":"632ec9ba-5bef-4ed3-a36d-56feec8ffd41",
    "endpoint_type":"mediator",
    "event_type":"binding",
    "number_dst":"15162065344",
    "number_redirect":"15162065346",
    "number_src":"15162065345",
    "partner_sid":"ed437757-002d-4ecc-aa5a-efdf5e50dba0",
    "reference_sid":"05561bef-ce48-4823-a847-bf10f7837a42",
    "type":"mediator",
    "version":2
}

The app_mediator callback is triggered when a call is made to a Mediator binding or from a Mediator dialout.

app_conference_call Callback

The app_conference_call callback response

{
    "address_dst": "\\"15162065515\\" \\u003csip:15162065515@11.22.33.44\\u003e",
    "address_src": "\\"1234\\" \\u003csip:+17605692222@12.34.56.78",
    "bridge": "conference-bridge",
    "call_sid": "69057c3e-bb90-4ed3-9c53-000000001090",
    "custom_call_type": "foreign",
    "custom_name": "\\u00271234\\u0027",
    "date_disconnected": "2021-12-14T07:08:01.000Z",
    "date_insert": "2021-12-14T07:40:27.706Z",
    "date_join": "2021-12-14T07:07:31.000Z",
    "date_start": "2021-12-14T07:07:09.000Z",
    "date_stop": "2021-12-14T07:08:01.000Z",
    "direction": "inbound",
    "disconnect_cause": 16,
    "disconnect_originator": "src",
    "disconnect_reason": "Normal",
    "duration": 50,
    "duration_meeting": 30,
    "endpoint_sid": "e3ddc435-7b07-4f3a-98d5-4fe9be107652",
    "meeting_room_sid": "f752b4a5-b821-4322-a26f-db5cfbf014ab",
    "meeting_sid": "69057c3e-bb90-4ed3-9c53-000000000373",
    "node": "11.22.33.44",
    "number_dst": "15162065515",
    "number_src": "+17605692222",
    "partner_sid": "cee93bf3-5746-43fe-a1a2-822c05fef687",
    "role": "participant",
    "user_agent": "CX-IVS-SBC"
}

The app_conference_call callback is triggered when the calling party calls a phone number associated with the Conference endpoint.

app_conference_meeting Callback

The app_conference_meeting callback response

{
    "attendee_count": 2,
    "audio_attendee_count": 2,
    "control_attendee_count": 0,
    "data_attendee_count": 0,
    "date_insert": "2021-12-14T07:40:33.843Z",
    "date_start": "2021-12-14T07:04:41.000Z",
    "date_stop": "2021-12-14T07:08:06.000Z",
    "duration": 205,
    "duration_audio": 205,
    "duration_control": 0,
    "duration_data": 0,
    "duration_meeting": 205,
    "duration_recording": 0,
    "duration_video": 0,
    "endpoint_sid": "e3ddc435-7b07-4f3a-98d5-4fe9be107652",
    "has_recording": false,
    "meeting_room_sid": "f752b4a5-b821-4322-a26f-db5cfbf014ab",
    "meeting_sid": "69057c3e-bb90-4ed3-9c53-000000000373",
    "partner_sid": "cee93bf3-5746-43fe-a1a2-822c05fef687",
    "unique_attendee_count": 2,
    "video_attendee_count": 0
}

The app_conference_meeting callback is triggered when the calling party joins a Conference meeting.

phonenumber_messaging_update Callback

The phonenumber_messaging_update callback response

{
    "did_sid":"d17a5391-1831-4d6b-adf0-5ba9a47ea6ad",
    "phonenumber":"13075220123",
    "messaging":{"enabled":true,"status":"enabled"}
}

The phonenumber_messaging_update callback is triggered when SMS/MMS messaging is enabled or disabled for a DID.

phonenumber_order Callback

The ` phonenumber_order` callback response

{
    "active_capabilities":4,
    "callback_url":"https://example.com/sms-callback-url",
    "campaign_sid": null, 
    "capabilities":7,
    "classification_sid":"d1a732b9-8530-499c-926a-e85282fc7387",
    "country_code":"CAN",
    "did_group_sid":null,
    "did_sid":"d713ea8a-c2ab-492f-85ac-83279ce4543e",
    "in_country_format":"(236) 804-0634",
    "international_format":"+1 236-804-0634",
    "locality":null,
    "lrn_sid":null,
    "name":"N/A",
    "partner_sid":"0a2015db-04dc-6fd1-8bd8-ebc2a815b58b",
    "phonenumber":"12368040634",
    "price":null,
    "state":null,
    "status":"assigned"
    "string_key_1":null,
    "string_key_2":null,
    "trunk_group_sid":null
}

The phonenumber_order callback is triggered when a DID from an external provider has been rented successfully.

Call Routing

CarrierX call routing connects IP communications infrastructure with the PSTN. Call routing works slightly differently depending on the direction of the communication, either inbound or outbound.

Hosted Endpoints: Conference, FlexML, and Mediator
Inbound communications come in from the PSTN and hit the CarrierX switches, which have configured trunks. Trunks are organized and managed in trunk groups. These entities hold settings that determine how the communication is processed. Outbound communications start from an IP-based application and move through a configurable SIP trunk, and are sent to the PSTN.

Third-Party Endpoints
Similar to hosted endpoints, inbound communications from the PSTN reach the CarrierX switches. The communications go through a configured trunk and then your external application. Outbound communications still come from your rented DIDs, but they go through your third-party configured endpoint, which integrates with an external IP. This communication still moves to the trunk and out to the PSTN.

The main difference is that the hosted endpoints (Conference, FlexML, and Mediator) are hosted by CarrierX. The third-party endpoint is hosted externally, not by CarrierX.

Transformations

Transformations look like the following

{
    "action":"set_header_parameter",
    "direction":"any",
    "operands":["P-Charging-Vector","orig-ioi","privateSIP"]
}

Note that you can use regular expressions in transformations. For example, the following will check if the phone number has a 1 prefix and add one if not.

{
    "transformations": [
        {
            "action": "rewrite_to",
            "direction": "any",
            "operands": ["^([2-9]\\d{9})$", "1\\1"]
        },
        {
            "action": "rewrite_from",
            "direction": "any",
            "operands": ["^([2-9]\\d{9})$", "1\\1"]
        }
    ]
}

Transformations are applied to endpoints, partners, DIDs, prefixes, trunk groups, and trunks. They modify values when an object is updated. Transformations have three parts: action, direction, and operands.

• action is what type of modification will be made. For example, rewrite_to rewrites the destination phone number.

• direction determines to which direction of traffic the transformation will apply. For example, if we set direction to outbound, the specific transformation will apply to sending voice calls only.

• operands are the items that are being acted upon. For example, rewrite_to accepts two operands: the value to replace and the value that it is going to be replaced with.

if_match

Sample if_match transformation

{
    "action": "if_match",
    "direction": "inbound",
    "operands": [
        "{{stir_verstat}}",
        "TN-Validation-Failed",
        "reject",
        "forbidden"
    ]
}

The if_match action is used to add conditions based on which other transformations are applied.

The action accepts from three to 100 operands: if_match(value, match, action, arg1, argX)

lookup_cic

Sample lookup_cic transformation

{
    "action": "lookup_cic",
    "direction": "inbound",
    "operands": [
        "false",
        "490",
        "{{src}}",
        "{{dst}}",
        "cic",
        "ignore",
        "e164",
        "guess"
    ]
}

The lookup_cic action is used to lookup the CIC (Carrier Identification Code) information for calls to toll-free phone numbers.

The action accepts eight operands: lookup_cic(force, lata, phonenumber_src, phonenumber_dst, destination, on_failure, input_format_src, input_format_dst)

lookup_cnam

Sample lookup_cnam transformation

{
    "action": "lookup_cnam",
    "direction": "inbound",
    "operands": [
        "true",
        "{{src}}",
        "{{src}}",
        "from"
    ]
}

The lookup_cnam action is used to lookup the CNAM information for the phone number.

The action accepts four operands: lookup_cnam(force, default, number, target)

lookup_rn

Sample lookup_rn transformation

{
    "action": "lookup_rn",
    "direction": "inbound",
    "operands": [
        "true",
        "true",
        "{{src}}",
        "from",
        "ignore",
        "e164",
        "domestic",
        "e164_with_plus",
        "passthrough"
    ]
}

The lookup_rn action is used to lookup the routing number and return it so that it could be used instead of the source or destination number.

The action accepts nine operands: lookup_rn(force, always, phonenumber, destination, on_failure, input_format, output_format_domestic, output_format_international, output_format_guess_not_found)

reject

Sample reject transformation

{
    "action": "reject",
    "direction": "inbound",
    "operands": [
        "busy"
    ]
}

The reject action is used to reject the call with one of the supported reasons.

The action accepts from one to two operands: reject(reason, message)

Reject Reasons

An example of the reject transformation with intermediary-rejected as a reject reason. My reason for rejecting the call will be returned as the additional message to the caller as a part of the Call-Info SIP header:

{
    "action": "reject",
    "direction": "inbound",
    "operands": [
        "intermediary-rejected",
        "My reason for rejecting the call"
    ]
}

Sample Call-Info SIP header returned from the above reject transformation with the intermediary-rejected reject reason

Call-Info: "My reason for rejecting the call"

rewrite_from

Sample rewrite_from transformation

{
    "action": "rewrite_from",
    "direction": "any",
    "operands": [
        "^([2-9]\\d{9})$",
        "1\\1"
    ]
}

The rewrite_from action is used to rewrite the phone number of the incoming call.

The action accepts two operands: rewrite_from(pattern, replace)

rewrite_from_header_param

Sample rewrite_from_header_param transformation

{
    "action": "rewrite_from_header_param",
    "direction": "any",
    "operands": [
        "cnam",
        "(.{1,14})",
        "\\1*"
    ]
}

The rewrite_from_header_param action is used to replace the parameters of the From header.

The action accepts three operands: rewrite_from_header_param(parameter, pattern, replace)

rewrite_header

Sample rewrite_header transformation

{
    "action": "rewrite_header",
    "direction": "any",
    "operands": [
        "X-Custom-Header",
        ":5060",
        ":6060",
        "sip:10.1.5.200:5060"
    ]
}

The rewrite_header action is used to replace the header (or a part of it) you specify as an operand with the new values, or create it, in the case the call data lacks it.

The action accepts four operands: rewrite_header(header, pattern, replace, default)

rewrite_header_parameter

Sample rewrite_header_parameter transformation

{
    "action": "rewrite_header_parameter",
    "direction": "any",
    "operands": [
        "Remote-Party-ID",
        "privacy",
        "full",
        "cnam",
        "id"
    ]
}

The rewrite_header_parameter action is used to replace the parameter of the header you specify as an operand with the new value, or create it, in the case the call data lacks it.

The action accepts five operands: rewrite_header_parameter(header, parameter, pattern, replace, default)

rewrite_to

Sample rewrite_to transformation

{
    "action": "rewrite_to",
    "direction": "any",
    "operands": [
        "^([2-9]\\d{9})$",
        "1\\1"
    ]
}

The rewrite_to action is used to rewrite the destination phone number.

The action accepts two operands: rewrite_to(pattern, replace)

rewrite_to_header_param

Sample rewrite_to_header_param transformation

{
    "action": "rewrite_to_header_param",
    "direction": "any",
    "operands": [
        "npdi",
        "yes",
        "no"
    ]
}

The rewrite_to_header_param action is used to replace the parameters of the To header.

The action accepts three operands: rewrite_to_header_param(parameter, pattern, replace)

set_header

Sample set_header transformation

{
    "action": "set_header",
    "direction": "any",
    "operands": [
        "X-Custom-Header",
        "sip:10.1.5.200:5060"
    ]
}

The set_header action is used to add a new header.

The action accepts two operands: set_header(header, value)

set_header_parameter

Sample set_header_parameter transformation

{
    "action": "set_header_parameter",
    "direction": "any",
    "operands": [
        "P-Charging-Vector",
        "orig-ioi",
        "privateSIP"
    ]
}

The set_header_parameter action is used to set a parameter to an existing header.

The action accepts three operands: set_header_parameter(header, parameter, value)

set_user_data

Sample set_user_data transformation

{
    "action": "set_user_data",
    "direction": "any",
    "operands": [
        "identity",
        "{{SipHeader_Identity}}"
    ]
}

The set_user_data action is used to add custom user data to the call detail records. The transformation saves the data as a JSON object to the user_data attribute of the Call Detail Record object.

The action accepts two operands: set_user_data(key, value)

sms_normalize

Sample sms_normalize transformation

{
    "action": "sms_normalize",
    "direction": "outbound",
    "operands": [
        "e164",
        "USA",
        "to",
        "ignore",
        "e164"
    ]
}

By default, all phone numbers for the SMS Object are always treated as E.164 international numbers.

The sms_normalize action is used to add a corresponding country prefix to the SMS Object from and/or to fields. This transformation is based on the Phonenumber Lookup object mechanism and the Phonenumber Lookup logic. With this transformation, for example, for all outbound messages you can indicate the country you need and by default all SMS messages with domestic number format in the to field will be routed to phone numbers inside that country, i.e. the system will be automatically converting such numbers to the E.164 format.

The action accepts five operands: sms_normalize(guess, country_code, field, on_failure, output_format)

stir_validate

Sample stir_validate transformation

{
    "action": "stir_validate",
    "direction": "any",
    "operands": []
}

The stir_validate action is used to validate the call and returns data that can be used with other transformations.

The action does not accept any operands, but instead enables the use of the following variables:

• {{stir_attest}} for the attestation level used for the call.
• {{stir_origid}} for the ID of the call originator.
• {{stir_verstat}} for the TN validation result (available values include TN-Validation-Passed, TN-Validation-Failed, and No-TN-Validation).

API Reference

The Core API has the following sections: Access Control, Apps, Batch, Calls, Countries, Endpoints, Billing, Lookup, OAuth, Partners, Phone Numbers, Push, Rating, Routing, Shortener, SMS, Storage, Trunk Groups, Text-To-Speech, Verification.

Access Control

Access Control consists of two concepts—Access Control Rules and Access Control Lists. Access Control Rules (ACRs) are criteria that can be applied to calls and SMS to form the building blocks of CarrierX access control policies. Access Control Lists (ACLs) combine ACRs and policy statements to determine if an action will be allowed or rejected.

Access Control List Object

This section describes the elements of the Access Control List object. These fields and values make up the JSON object that gets returned with successful requests.

Sample Access Control List object

{
    "access_control_rules": [
        "dafd993d-0e99-4af9-b8fc-436fb01b0bbe",
        "6fd782fa-c80b-4299-9b91-78797eb392e1"
    ],
    "direction": "outbound",
    "sms_action_false": null,
    "sms_action_true": null,
    "voice_action_false": null,
    "voice_action_true": "reject503"
}

* Please note that for the Trunk Group and the Trunk objects these fields are always null and read-only because Trunk Groups and Trunks are used for voice only.

Look Up Effective ACLs for Calls

GET /accesscontrol/effective_acl/calls
Returns effective ACLs for calls

curl -X GET \
'https://api.carrierx.com/core/v2/accesscontrol/effective_acl/calls' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 200 status code with a list of Access Control List objects

{
    "count": 1,
    "has_more": false,
    "items": [
        {
            "effective_acls": [
                {
                    "access_control_rules": [
                        "dafd993d-0e99-4af9-b8fc-436fb01b0bbe",
                        "6fd782fa-c80b-4299-9b91-78797eb392e1"
                    ],
                    "direction": "outbound",
                    "sms_action_false": null,
                    "sms_action_true": null,
                    "voice_action_false": null,
                    "voice_action_true": "reject503"
                }
            ],
            "layer": 1
        }
    ],
    "limit": 1,
    "offset": 0,
    "pagination": {},
    "total": 1
}

This request returns a list of effective Access Control Lists (ACLs) for calls for the partner or trunk group, targeted by secure ID.

This request is enabled for Field Filtering. Additionally, query arguments are used to narrow the results.

Required Scopes

To get information about Access Control Lists the partner must have one of the following scopes enabled:

• accesscontrol.manage
• accesscontrol.read

Query Arguments

Look Up Effective ACLs for SMS

GET /accesscontrol/effective_acl/sms
Returns effective ACLS for SMS

curl -X GET \
'https://api.carrierx.com/core/v2/accesscontrol/effective_acl/sms' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 200 status code with a list of Access Control List objects

{
    "count": 1,
    "has_more": false,
    "items": [
        {
            "effective_acls": [
                {
                    "access_control_rules": [
                        "93525bae-f9a9-446b-b92a-7f421df7a11e"
                    ],
                    "direction": "outbound",
                    "sms_action_false": null,
                    "sms_action_true": "accept",
                    "voice_action_false": null,
                    "voice_action_true": null
                }
            ],
            "layer": 1
        }
    ],
    "limit": 1,
    "offset": 0,
    "pagination": {},
    "total": 1
}

This request returns the list of effective Access Control Lists (ACLs) for SMS for the partner, targeted by secure ID.

This request is enabled for Field Filtering. Additionally, query arguments are used to narrow the results.

Required Scopes

To get information about Access Control Rules the partner must have one of the following scopes enabled:

• accesscontrol.manage
• accesscontrol.read

Query Arguments

Access Control Rule Object

This section describes the elements of the Access Control Rule object. These fields and values make up the JSON object that gets returned with successful requests.

Sample Access Control Rule object

{
    "entries": [
        "1800",
        "1615"
    ],
    "field": "to",
    "name": "N/A",
    "operation": "prefix",
    "quantifier": "any",
    "read_only": false,
    "rule_sid": "c9109b54-13f2-4157-ba23-2984b3a207dc"
}

Create Access Control Rule

POST /accesscontrol/rules
Creates an access control rule

curl -X POST \
'https://api.carrierx.com/core/v2/accesscontrol/rules' \
-H 'Content-Type: application/json' \
--data-binary '{"field":"to", "quantifier":"any", "entries": ["1800","1615"], "operation":"prefix"}' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 200 status code with a serialized copy of the Access Control Rule object

{
    "entries": [
        "1800",
        "1615"
    ],
    "field": "to",
    "name": "N/A",
    "operation": "prefix",
    "quantifier": "any",
    "read_only": false,
    "rule_sid": "c9109b54-13f2-4157-ba23-2984b3a207dc"
}

This request adds a new Access Control Rule (ACR) for the currently logged in partner.

Required Scopes

To create an Access Control Rule object, the partner must have one of the following scopes enabled:

• accesscontrol.manage
• accesscontrol.create

Body Arguments

JSON representation of the fields and values of the Access Control Rule object to be created.

Required fields to create an access control rule are:

• entries
• field
• operation
• quantifier

The field parameter should contain the value against which messages or calls will be checked.

• The calling and called field values are specific for voice calls.
• The from (some legacy users may still see the old naming from_did), to (to_did) and message field values are specific for SMS.

Refer to this table to view all fields that appear in the Access Control Rule object.

Get Access Control Rules

GET /accesscontrol/rules
Returns access control rules matching the criteria in the request URL

curl -X GET \
'https://api.carrierx.com/core/v2/accesscontrol/rules?offset=0&limit=1' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 200 status code with a list of Access Control Rule objects

{
    "count": 1,
    "has_more": true,
    "items": [
        {
            "entries": [
                "18007"
            ],
            "field": "called",
            "name": "1st",
            "operation": "prefix",
            "quantifier": "any",
            "read_only": true,
            "rule_sid": "dafd993d-0e99-4af9-b8fc-436fb01b0bbe"
        }
    ],
    "limit": 1,
    "offset": 0,
    "pagination": {
        "next": "https://api.carrierx.com/core/v2/accesscontrol/rules?limit=1&offset=1"
    },
    "total": 56
}

This request returns a list of Access Control Rules (ACRs) that match the given criteria, and that belong to the currently logged-in partner and parent partner.

A partner will not be able to view ACRs created by sub-partners. The read_only field shows whether or not the ACRs belong to the currently logged-in partner.

This request is enabled for Pagination, Result Filtering, and Field Filtering.

Required Scopes

To get information about Access Control Rule objects, the partner must have one of the following scopes enabled:

• accesscontrol.manage
• accesscontrol.read

Get Access Control Rule by SID

GET /accesscontrol/rules/{rule_sid}
Returns an access control rule, targeted by secure ID

curl -X GET \
'https://api.carrierx.com/core/v2/accesscontrol/rules/dafd993d-0e99-4af9-b8fc-436fb01b0bbe' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 200 status code with a serialized copy of the Access Control Rule object

{
    "entries": [
        "18007"
    ],
    "field": "called",
    "name": "1st",
    "operation": "prefix",
    "quantifier": "any",
    "read_only": true,
    "rule_sid": "dafd993d-0e99-4af9-b8fc-436fb01b0bbe"
}

This request returns data for a particular access control rule (ACR), targeted by secure ID.

Returned ACRs apply to the partner and the parent partner.

This request is enabled for Field Filtering.

Required Scopes

To get information about an Access Control Rule object, the partner must have one of the following scopes enabled:

• accesscontrol.manage
• accesscontrol.read

Path Arguments

Update Access Control Rule

PATCH /accesscontrol/rules/{rule_sid}
Updates the Access Control Rule object, targeted by secure ID, with the values in the request body

curl -X PATCH \
'https://api.carrierx.com/core/v2/accesscontrol/rules/c9109b54-13f2-4157-ba23-2984b3a207dc' \
-H 'Content-Type: application/json' \
--data-binary '{"operation":"exact"}' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 200 status code with a serialized copy of the updated Access Control Rule object

{
    "entries": [
        "1800",
        "1615"
    ],
    "field": "to",
    "name": "N/A",
    "operation": "exact",
    "quantifier": "any",
    "read_only": false,
    "rule_sid": "c9109b54-13f2-4157-ba23-2984b3a207dc"
}

This request updates an access control rule, targeted by secure ID.

An Access Control Rule object can be updated using either a PATCH or PUT request.

• A PATCH request can be used to update one or more attribute values. When using a PATCH request, only the attributes specified in the request payload will be updated, all other attributes and values will remain the same. The access control rule secure ID is passed in the query URL, and the values to be modified are passed in the request body.

• A PUT request can be used to update an entire Access Control Rule object. The access control rule secure ID is passed in the query URL, and the entire Access Control Rule object is passed in the request body.

Required Scopes

To update an Access Control Rule object, the partner must have one of the following scopes enabled:

• accesscontrol.manage
• accesscontrol.update

Path Arguments

Body Arguments

JSON representation of the fields and values to be updated.

Fields that can be modified are:

• entries
• field
• name
• operation
• quantifier

Refer to this table to view all fields that appear in the Access Control Rule object.

Delete Access Control Rule

DELETE /accesscontrol/rules/{rule_sid}
Deletes an Access Control Rule, targeted by secure ID

curl -X DELETE \
'https://api.carrierx.com/core/v2/accesscontrol/rules/c9109b54-13f2-4157-ba23-2984b3a207dc' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 204 status code with an empty body

This request deletes an Access Control Rule object, targeted by secure ID.

ACRs can only be deleted when associated with the partner. Partners cannot delete an ACR for a parent partner when the value of read_only is true.

Required Scopes

To delete an Access Control Rule object, the partner must have one of the following scopes enabled:

• accesscontrol.manage
• accesscontrol.delete

Path Arguments

Apps

The Apps API is used to display the detailed records of the calls made to the Conference and Mediator endpoints.

With Conference endpoints, the events associated with calling into the meeting trigger the creation of the App DR Conf CDR objects. When the calling party joins the meeting, this creates a related App DR Conf MDR object.

With Mediator endpoints, the events associated with the calls made to the bindings or from the dialouts trigger creation of the App DR Mediator objects. These detail records become available after the call is ended.

App DR Conf CDR Object

This section describes the elements of the App DR Conf CDR object. These fields and values make up the JSON object that gets returned with successful requests.

Sample App DR Conf CDR Object object

{
    "address_dst": "\"15162065515\" <sip:15162065515@11.22.33.44>",
    "address_src": "<sip:+17605692222@12.34.56.78",
    "audio_key": null,
    "bridge": "conference-bridge",
    "call_sid": "69057c3e-bb90-4ed3-9c53-000000001142",
    "custom_call_type": null,
    "custom_name": null,
    "date_disconnected": "2021-12-14T10:04:04.000Z",
    "date_insert": "2021-12-14T11:01:03.195Z",
    "date_join": "2021-12-14T10:03:30.000Z",
    "date_start": "2021-12-14T10:03:14.000Z",
    "date_stop": "2021-12-14T10:04:04.000Z",
    "direction": "inbound",
    "disconnect_cause": 16,
    "disconnect_originator": "src",
    "disconnect_reason": "Normal",
    "duration": "50",
    "duration_meeting": "34",
    "endpoint_sid": "e3ddc435-7b07-4f3a-98d5-4fe9be107652",
    "meeting_room_sid": "f752b4a5-b821-4322-a26f-db5cfbf014ab",
    "meeting_sid": "69057c3e-bb90-4ed3-9c53-000000000392",
    "node": "11.22.33.44",
    "number_dst": "15162065515",
    "number_src": "+17605692222",
    "partner_sid": "cee93bf3-5746-43fe-a1a2-822c05fef687",
    "role": "host",
    "user_agent": "CX-IVS-SBC"
}

Get Conference Calls

GET /app/conference/calls
Returns Conference endpoint Call object call detail records matching the criteria in the request URL

curl -X GET \
'https://api.carrierx.com/core/v2/app/conference/calls' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 200 response code with a list of App DR Conf CDR objects

{
    "count": 1,
    "has_more": false,
    "items": [
        {
            "address_dst": "\"15162065515\" <sip:15162065515@11.22.33.44>",
            "address_src": "<sip:+17605692222@12.34.56.78",
            "audio_key": null,
            "bridge": "conference-bridge",
            "call_sid": "69057c3e-bb90-4ed3-9c53-000000001142",
            "custom_call_type": null,
            "custom_name": null,
            "date_disconnected": "2021-12-14T10:04:04.000Z",
            "date_insert": "2021-12-14T11:01:03.195Z",
            "date_join": "2021-12-14T10:03:30.000Z",
            "date_start": "2021-12-14T10:03:14.000Z",
            "date_stop": "2021-12-14T10:04:04.000Z",
            "direction": "inbound",
            "disconnect_cause": 16,
            "disconnect_originator": "src",
            "disconnect_reason": "Normal",
            "duration": "50",
            "duration_meeting": "34",
            "endpoint_sid": "e3ddc435-7b07-4f3a-98d5-4fe9be107652",
            "meeting_room_sid": "f752b4a5-b821-4322-a26f-db5cfbf014ab",
            "meeting_sid": "69057c3e-bb90-4ed3-9c53-000000000392",
            "node": "11.22.33.44",
            "number_dst": "15162065515",
            "number_src": "+17605692222",
            "partner_sid": "cee93bf3-5746-43fe-a1a2-822c05fef687",
            "role": "host",
            "user_agent": "CX-IVS-SBC"
        }
    ],
    "limit": 10,
    "offset": 0,
    "pagination": {},
    "total": null
}

This request returns a list of call detail records related to the Conference Call objects.

This request is enabled for Pagination, Result Filtering, and Field Filtering.

Required Scopes

To get information about App DR Conf CDR objects, the partner must have one of the following scopes enabled:

• app.manage
• app.read

To view information about App DR Conf CDR objects for the inherited partner, the partner must additionally have the app.read_descendant scope enabled.

Get Conference Call by SID

GET /app/conference/calls/{call_sid}
Returns a call detail record related to Conference call, targeted by secure ID

curl -X GET \
'https://api.carrierx.com/core/v2/app/conference/calls/69057c3e-bb90-4ed3-9c53-000000001142' \
-H 'Authorization: Bearer 5ebc03d6-8b2b-44ad-bf65-72d4f1491dda'

Response 200 response code with a serialized copy of the App DR Conf CDR object

{
    "address_dst": "\"15162065515\" <sip:15162065515@11.22.33.44>",
    "address_src": "<sip:+17605692222@12.34.56.78",
    "audio_key": null,
    "bridge": "conference-bridge",
    "call_sid": "69057c3e-bb90-4ed3-9c53-000000001142",
    "custom_call_type": null,
    "custom_name": null,
    "date_disconnected": "2021-12-14T10:04:04.000Z",
    "date_insert": "2021-12-14T11:01:03.195Z",
    "date_join": "2021-12-14T10:03:30.000Z",
    "date_start": "2021-12-14T10:03:14.000Z",
    "date_stop": "2021-12-14T10:04:04.000Z",
    "direction": "inbound",
    "disconnect_cause": 16,
    "disconnect_originator": "src",
    "disconnect_reason": "Normal",
    "duration": "50",
    "duration_meeting": "34",
    "endpoint_sid": "e3ddc435-7b07-4f3a-98d5-4fe9be107652",
    "meeting_room_sid": "f752b4a5-b821-4322-a26f-db5cfbf014ab",
    "meeting_sid": "69057c3e-bb90-4ed3-9c53-000000000392",
    "node": "11.22.33.44",
    "number_dst": "15162065515",
    "number_src": "+17605692222",
    "partner_sid": "cee93bf3-5746-43fe-a1a2-822c05fef687",
    "role": "host",
    "user_agent": "CX-IVS-SBC"
}

This request returns data for a Conference call, targeted by secure ID.

This request is enabled for Field Filtering.

Required Scopes

To get information about an App DR Conf CDR object, the partner must have one of the following scopes enabled:

• app.manage
• app.read

To view information about App DR Conf CDR objects for the inherited partner, the partner must additionally have the app.read_descendant scope enabled.

Path Arguments

App DR Conf MDR Object

This section describes the elements of the App DR Conf MDR object. These fields and values make up the JSON object that gets returned with successful requests.

Sample App DR Conf MDR Object object

{
    "attendee_count": 2,
    "audio_attendee_count": 2,
    "control_attendee_count": 0,
    "data_attendee_count": 0,
    "date_insert": "2021-12-14T11:01:20.224Z",
    "date_start": "2021-12-14T10:02:26.000Z",
    "date_stop": "2021-12-14T10:04:04.000Z",
    "duration": "98",
    "duration_audio": "98",
    "duration_control": "0",
    "duration_data": "0",
    "duration_meeting": "98",
    "duration_recording": "0",
    "duration_video": "0",
    "endpoint_sid": "e3ddc435-7b07-4f3a-98d5-4fe9be107652",
    "has_recording": false,
    "meeting_room_sid": "f752b4a5-b821-4322-a26f-db5cfbf014ab",
    "meeting_sid": "69057c3e-bb90-4ed3-9c53-000000000392",
    "partner_sid": "cee93bf3-5746-43fe-a1a2-822c05fef687",
    "unique_attendee_count": 2,
    "video_attendee_count": 0
}