REST API Basic Structure and Specifications
1. Overview and structure
In the REST API, APIs are categorized by function, such as power control, volume adjustment, and input switching. In addition, function names are included in corresponding endpoint URLs. Request and response data specifications are also defined, enabling selective implementation of only required controls.
Available API Services
| Service | Description |
|---|---|
| guide | The guide service provides an API to retrieve the list of supported services on the server. |
| appControl | This service handles APIs that are for launching the application itself, and the accompanying manipulations related to specific applications. |
| audio | This service handles APIs that are related to audio functions like volume, sound effects, and so on. |
| avContent | This service handles the overall control of input and output of the monitor for AV contents and manipulating AV Contents itself on the monitor. |
| encryption | This service handles APIs that are related to encryption. |
| system | This service handles APIs that are related to basic monitor functions. |
| videoScreen | This service handles APIs that are related to video screen functions. |
Example for URL
The Base URL consists of an IP address or hostname, plus /sony.
[IP address] or [Host name]/sony
Service APIs can be accessed using the following URL structure.
http://[IP address] or [Host name]/sony/[service name]- A URL with a slash (/) at the end of the service name is invalid.
- Each service is independent. APIs are called using their corresponding service URLs.
Example for guide services (IP: 192.168.0.1)
http://192.168.0.1/sony/guide
2. REST API version specifications and request structure
The REST API is version-managed. Two types of versions are defined: the version specific to each API and the overall REST API version. These indicate the REST API version (generation version) and API-specific versions supported by the display.
How to Find the REST API Version Your Display Supports
Check the supported REST API version in the getSystemInformation response.
Example Request
{
"method": "getSystemInformation",
"id": 33,
"params": [],
"version": "1.0"
}Example Response
{
"result": [{
"product": "TV",
"region": "",
"language": "eng",
"model": "FW-85BZ35P",
"serial": "1000001",
"macAddr": "12:34:56:78:9A:BC",
"name": "BRAVIA",
"generation": "6.5.0",
"area": "ZZZ",
"cid": "01234567890123456789012345678901"
}],
"id": 33
}- “audio”: The API-specific version v1.0 and the overall REST API version (generation version) v5.0.0 are available.
- The same applies to “video” and “system.”
Refer to “How to Find the REST API Version Your Display Supports” to verify the version and use the corresponding APIs.
3. JSON-RPC specification, extensions, and limitations
The REST API defines its own extended format in addition to the standard JSON format. The API also has certain limitations.
JSON-RPC Data Types
| Type | Explanation |
|---|---|
| boolean | A boolean value is stored. |
| boolean-array | Multiple true or false values are stored in an array. |
| integer | An integer ranging from -2147483648 to 2147483647 is stored. |
| integer-array | Multiple integers are stored in an array. |
| double | A floating-point number ranging from -2.2250738585072014e-308 to 1.7976931348623157e+308 is stored. |
| double-array | Multiple floating-point numbers are stored in an array. |
| string | A string is stored. Unless otherwise mentioned in each API specification, it is encoded in UTF-8. |
| string-array | Multiple strings are stored in an array. |
Extensions
- Successful responses ignore the “error” field. Failed responses omit the “result” field.
- “error” is an array in the format [error_code, error_message].
- “error_code” is an integer.
- “error_message” is a debug string and should not be used to control behavior.
- Specify “version” in the request (e.g., “1.0”) to maintain client compatibility.
Limitations
- “null” is generally an invalid parameter.
- “params” and “result” are fixed-length arrays as defined in the API specification.
- Use an integer from 1 to 2147483647 for “id” (0 is reserved and cannot be used).
Example for JSON-RPC
Request
{"method": "echo", "params": ["Hello REST API"], "id": 1}
Response (Success)
{"result": [{"name": "Alice"}], "id": 2}
Response (Failure)
{"error": [401, "Unauthorized"], "id": 2}
4. Internal description conventions in the API specification
| Multiplicity | 1: Required Once ?: Zero or Once *: Zero or More |
| Default | Default is the value that the data receiver must regard as if it were sent from the sender in case specific parameters are missing. |
| Date | This product uses ISO 8601 for date and time format. |
| Country | This product uses ISO 3166 alpha 2 and additional codes for country codes. |
5. Pre-Shared Key access control by level
The Pre-shared key authentication system is managed through a hierarchy of three authentication levels.
private:
Highest authentication level. Used for APIs that handle personally identifiable information (such as device IDs) or user-specific information. Authentication is mandatory.
generic:
Used for APIs that perform device control or change device status. Authentication is required.
none:
Used for APIs that do not require authentication.
Clients can access APIs at their authentication level or below. For example, a client with private-level authentication can also access generic and none-level APIs. However, a client with only generic-level authentication cannot access private-level APIs.
The monitor controls access based on the authentication level defined for each API.
POST /sony/system HTTP/1.1
Host: 192.168.0.1 Accept: */*
Cache-Control: no-cache
Connection: close
Content-Type: application/json; charset=UTF-8
Pragma: no-cache
X-Auth-PSK: 1234
Content-Length: 70 {"method": "getPowerStatus", "params": [], "id": 50, "version": "1.0"}6. Encryption system
The encryption system is a built-in feature provided with BRAVIA Professional Displays and is available through the encryption API, which encrypts and decrypts string parameters using standard 2048/1024-bit RSA (RFC 3447) and 128-bit AES-CBC (RFC 3602) algorithms to ensure that communication of those parameters is secure.
Note:
The encryption system prevents communication interception. It does not prevent unauthorized access or spoofing. This method encrypts only specific parameters, not the entire communication. Communication is conducted in the same manner as standard JSON protocol communication.
Encryption flow
1.Send Flow
The encryption system uses a hybrid method combining RSA public keys and AES symmetric keys. Sensitive data is encrypted with the AES symmetric key. RSA public keys are used to securely share the symmetric key between clients and the monitor.
Encrypted Send Flow Diagram
- Preparation
The monitor creates an RSA key pair. The client creates an AES key and encrypts it with the RSA public key. - Send
The client encrypts sensitive data with the AES key and sends it to the monitor along with the encrypted AES key. - Receive
The monitor uses the RSA private key to decrypt the symmetric key. It then uses the decrypted symmetric key to decrypt the data.

2.Receive Flow
Encryption works the same way when sending data from the monitor to the client. After prior key preparation (RSA key pair generation, AES key generation), encrypted data and the encrypted AES key are communicated. Even if the communication is intercepted, it cannot be decrypted by a third party.
Encrypted Receive Flow Diagram

3.”getPublicKey” Definition
The getPublicKey method is a common API in the encryption system. Other APIs that send or retrieve encrypted parameters have an encKey element and at least one encrypted data element. If an API has multiple encrypted elements, a shared encKey must be included in params.
Example for JSON Send
{
"method":"sendSecretData",
"params":[
{
"secretData1":"G9KgQDustrxplKFcy9fnVQ==",
"secretData2":"At2gQDgst6xplKFcy9fnVQ==",
"encKey":"hCkxUu4WydqDwrlq+PsSSxBaIVbPFNeCU7XYgBC9bVmXvcTORXMdY5FeSr3LYu9WywFbh1WwTBW/S+xTPHZQXhQMUsWEFQwUSldm5xK8vhOcdzGe8kdrixAL6zL9qx6rioR95gF50FO1RRVS7jdsabPvHK5gXZHM9B2h24QKON1FeTkYVGKcf8J3JJp9gEWeNYG2bfMSvnS9qrn2bLXgAX71vwEz7Btm/+qmX7/nsrL5QGBdbgxUlK7q5JzZxOdDuh592lfdEoMIgFR144XAnhfqyCcuZLJ/60VjOpREQ17vTj6+NNVrSOIq4eHnBlB7SfFWM/CBa+rCFmYAzmm3VQ=="
}
],
"id":1,
"version":"1.0"
}
{
"result":[],
"id":1
}Example for JSON get
{
"method":"getSecretData",
"params":[
{
"encKey":"hCkxUu4WydqDwrlq+PsSSxBaIVbPFNeCU7XYgBC9bVmXvcTORXMdY5FeSr3LYu9WywFbh1WwTBW/S+xTPHZQXhQMUsWEFQwUSldm5xK8vhOcdzGe8kdrixAL6zL9qx6rioR95gF50FO1RRVS7jdsabPvHK5gXZHM9B2h24QKON1FeTkYVGKcf8J3JJp9gEWeNYG2bfMSvnS9qrn2bLXgAX71vwEz7Btm/+qmX7/nsrL5QGBdbgxUlK7q5JzZxOdDuh592lfdEoMIgFR144XAnhfqyCcuZLJ/60VjOpREQ17vTj6+NNVrSOIq4eHnBlB7SfFWM/CBa+rCFmYAzmm3VQ=="
}
],
"id":1,
"version":"1.0"
}
{
"result":[
{
"secretData":"G9KgQDustrxplKFcy9fnVQ=="
}
],
"id":1
}4.Implementation Guide
The monitor generates an RSA public/private key pair when powered on. RSA key generation is time-consuming. Set the bit size and management method based on your monitor specifications.
Client Initialization Procedure
- Call “getPublicKey” to retrieve the monitor’s public key.
- Generate an AES symmetric key and encrypt it with the RSA public key to create encKey.
- Use these keys to call the encryption API.
Note:
Do not change keys after initialization to maintain consistency.
The encryption key size can be defined by each system. Use a key size that considers security. Clients can use the same symmetric key for different API calls. Additionally, if necessary, clients can recreate the symmetric key and encKey to improve security.
Error Handling
If the encryption module fails to encrypt or decrypt due to an invalid state such as key mismatch, the monitor returns a 40002 Encryption Failed error. If the client receives this error, retry the initialization procedure (starting from calling getPublicKey).
7. Device resource URI
In REST API, display resources are represented using the standard URI structure defined in RFC 3986. Please note that URIs are provided by the display and cannot be changed or modified on the client side.
Scheme Definition
Basic Scheme
| Scheme | Type | Description |
|---|---|---|
| extInput | input resource | External input resource |
Detailed Scheme
| Scheme | Source | Description |
|---|---|---|
| extInput | extInput:cec | CEC input resource. |
| extInput | extInput:component | Component external input resource. |
| extInput | extInput:composite | Composite external input resource. |
| extInput | extInput:hdmi | HDMI external input resource. |
| extInput | extInput:widi | Wi-Fi Display external input resource. |
Examples for URI Usage
| Input Type | URI Example | Description |
|---|---|---|
| HDMI | extInput:hdmi?port=1 | HDMI 1 |
| HDMI | extInput:hdmi?port=2 | HDMI 2 |
| HDMI | extInput:hdmi?port=3 | HDMI 3 |
| HDMI | extInput:hdmi?port=4 | HDMI 4 |
| Component | extInput:component?port=1 | Component 1 |
| Component | extInput:component?port=2 | Component 2 |
| Component | extInput:component?port=3 | Component 3 |
| Component | extInput:component?port=4 | Component 4 |
| Wi-Fi Display | extInput:widi?port=1 | Wi-Fi Display |
| CEC Recorder | extInput:cec?type=recorder&port=1 | Recorder 1 |
| CEC Recorder | extInput:cec?type=recorder&port=2 | Recorder 2 |
| CEC Recorder | extInput:cec?type=recorder&port=3 | Recorder 3 |
| CEC Player | extInput:cec?type=player&port=1 | Player 1 |
| CEC Player | extInput:cec?type=player&port=2 | Player 2 |
| CEC Player | extInput:cec?type=player&port=3 | Player 3 |
| CEC Tuner | extInput:cec?type=tuner&port=1 | Tuner 1 |
| CEC Tuner | extInput:cec?type=tuner&port=2 | Tuner 2 |
| CEC Tuner | extInput:cec?type=tuner&port=3 | Tuner 3 |
| Other CEC Device | extInput:cec?type=freeuse | General CEC device |