document

Service endpoint

Production Server https://asr.ilivedata.com/api/v1/speech/recognize

Request headers

Request body

Sample Request**

{
  "languageCode": "zh-CN",
  "config": {
   	"codec": "OPUS",
   	"sampleRateHertz": 16000
  },
  "audio":"T2dnUwACAAAAAAAAAAAd8pVTAAAAAGsIvpMBE..."
}

Authentication

Requests to Speech Recognition API must be signed - that is, they must include information that Speech Recognition API can use to authenticate the requestor. Requests are signed using the appId and secretKey which are issued to your application.  To sign a request, you use some values from the request, and your secret key to create a signed hash - this is the signature. You can then add the signature to the request using the HTTP Authorization header. 

How to Generate a Signature for a Request to Speech Recognition API

1. Create the canonicalized query string that you need later in this procedure:

   1. SHA256 digest of the query body, normally it will be a JSON string.

   2. Convert the digest bytes to HEX string

2. Create the string to sign according to the following pseudo-grammar (the “\n” represents an ASCII newline character).

StringToSign = HTTPMethod + "\n" + 
               HostHeaderInLowercase + "\n" + 
               HTTPRequestURI + "\n" + 
               CanonicalizedQueryString <from the preceding step> + "\n" +
               "X-AppId:" + SAME_APPID_IN_HEADER + "\n" + 
               "X-TimeStamp:" + SAME_TIMESTAMP_IN_HEADER

1. The HTTPRequestURI component is the HTTP absolute path component of the URI up to, but not including, the query string. If the HTTPRequestURI is empty, use a forward slash ( / ).

2. Calculate an RFC 2104-compliant HMAC with the string you just created, your Secret Key as the key, and SHA256  as the hash algorithm. For more information, see http://www.ietf.org/rfc/rfc2104.txt.

3. Convert the resulting value to base64.

4. Use the resulting value as the value of the Authorization HTTP header.

  Important The final signature you send in the request must be URL encoded as specified in RFC 3986 (for more information, see http://www.ietf.org/rfc/rfc3986.txt). If your toolkit URL encodes your final request, then it handles the required URL encoding of the signature. If your toolkit doesn’t URL encode the final request, then make sure to URL encode the signature before you include it in the request. Most importantly, make sure the signature is URL encoded only once. A common mistake is to URL encode it manually during signature formation, and then again when the toolkit URL encodes the entire request. Some toolkits implement RFC 1738, which has different rules than RFC 3986 (for more information, go to http://www.ietf.org/rfc/rfc1738.txt).  

Response body

Sample Response**

{
    "errorCode": 0,
    "transcript": {
        "languageCode": "zh-CN",
        "text": "杭州822路公交车经过站点。",
        "confidence": 0.0,
        "duration": 4881.770833333333
    }
}

Error Code