AnswerX Reputation Knowledge Server API v1
Configure custom DNS behavior based on rules stored in Akamai's Reputation Knowledge Server (RKS).
Learn more:
Overview
AnswerX is an intelligent, recursive DNS platform and product designed to manage DNS traffic. AnswerX is subscriber-aware, which allows users to offer value-added service options such as parental controls and fast access to preferred websites while enhancing the user’s ability to deliver better, faster service to subscribers. AnswerX can process millions of DNS transactions per second and offers best-in-class total cost of ownership. There are three versions of AnswerX:
AnswerX Licensed runs in the carrier’s network and Akamai provides system support.
AnswerX Cloud is a cloud service managed and maintained using Akamai’s network. This has the advantage of requiring few resources from a customer. The configuration uses Akamai rack space, power, and other related equipment. The service will still be configured individually per customer, but it will run on shared capacity in locations where Akamai believes it is the most effective.
AnswerX Managed completely manages the servers in the carrier’s network and customers do not have access to the systems. This has the advantage of being dedicated capacity. Since it runs in the carrier network, it can be deployed close to the end clients to provide the best possible DNS resolution times.
The AnswerX RKS API lets you configure custom DNS behavior based on rules. These rules are stored in the Reputation Knowledge Server (RKS). RKS is a distributed database containing two types of tables, “static” and “real-time” (RTT). Certain API calls only work on one type of table or the other as indicated below.
You can call this API with two different URI schema types. The first
type assumes that the caller knows their service instance ID. The
second type requires only the product’s name (for example, managed
or cloud
) and the contract ID. Both formats have the same behavior
and are documented here.
For API calls that have a key field, the key is always matched against
the first column in the table (that is, the leftmost column is the key
column). If the key column is of type STRING, then the key in the URI
must be enclosed in URI-encoded double quotes (%22KEY%22
).
Who should use this API
This API is for site administrators, project managers, and technical support providers who will implement AnswerX for your organization. It assumes that you have a working knowledge of AnswerX and how it uses RKS data. If you are not familiar with these topics, see the AnswerX product page.
Get started
Review Get Started with APIs for details on how to set up client tokens to access any Akamai API. These tokens appear as custom hostnames that look like this:
https://akzz-XXXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXX.luna.akamaiapis.net
.To enable this API, choose the API service named AnswerX RKS, and set the access level to READ-WRITE.
Visit the akamai-open repository to download reference EdgeGrid clients and sample code.
Get help from the Akamai developer community.
The Recursive DNS DB API lets users of RKS view, modify, add, and delete data in their RKS tables. For more information about AnswerX and RKS, see the AnswerX product page.
The RKS table system is a part of Akamai’s AnswerX Recursive Nameserver product. This API lets users make changes to their RKS tables, including viewing table contents, viewing individual rows, and, for dynamic tables, adding, modifying, and deleting rows.
The API supports XML and JSON data formats. JSON is the default. To
update or add a new row in a table, your JSON or XML should contain a
list of all non-key columns, with the type and new value of each
column listed. You may also provide an optional Expiry
field, which
specifies a time-to-live for the row, in seconds. The allowed column
types are INT
, UINT64
, STRING
, or CIDR
.
For all REST methods (GET, PUT/POST, and DELETE), there are two ways to access your data: instance ID or product type and contract ID. Assuming the table to be accessed is named TABLE, the URL format for these, respectively, is:
/recursive-dns-db/v1/service-instances/ID/tables/TABLE/...
/recursive-dns-db/v1/product-types/PROD/contracts/CID/recursive-db/tables/TABLE
The key column is given as part of the URL (for complete details on the JSON and XML formats, and the REST calls, see the Resources section.
For example, you have a dynamic table called IPToSubscriber. The key field for this table is an IP address in CIDR notation, and there are five other columns. To update a row for 1.2.3.4/32, for service instance ID 20 using JSON, you might submit the following:
PUT /recursive-dns-db/v1/service-instances/20/tables/IPToSubscriberTable?key=1%2E2%2E3%2E4%2F32 HTTP/1.1
Content-type: application/json
Content-length: 268
{
"Columns": [
{
"Type": "STRING",
"Value": "This is my first string"
},
{
"Type": "INT",
"Value": "100"
},
{
"Type": "INT",
"Value": "200"
},
{
"Type": "INT",
"Value": "300"
},
{
"Type": "STRING",
"Value": "AnotherStringHere"
}
],
"Expiry": 86400
}
The same row update in XML format will look like this:
PUT /recursive-dns-db/v1/service-instances/20/tables/IPToSubscriberTable?key=1%2E2%2E3%2E4%2F32 HTTP/1.1
Content-type: application/xml
Content-length: 350
<Row>
<Columns>
<Column>
<Value>This is my first string</Value>
<Type>STRING</Type>
</Column>
<Column>
<Value>100</Value>
<Type>INT</Type>
</Column>
<Column>
<Value>200</Value>
<Type>INT</Type>
</Column>
<Column>
<Value>300</Value>
<Type>INT</Type>
</Column>
<Column>
<Value>AnotherStringHere</Value>
<Type>STRING</Type>
</Column>
</Columns>
<Expiry>86400</Expiry>
</Row>
You can also fetch data with a GET request or delete data with a DELETE request. For GET, indicate your preferred format (JSON or XML) in the Accept header. If you omit the header, the format defaults to JSON.
Resources
The AnswerX API lets you interact with table data using two different
endpoints whose responses are formatted identically. One assumes you
know the unique service instance identifier, and the other requires
only the contract identifier and product name, such as managed
or
cloud
.
API operations specify table rows with a unique key
parameter, which
matches the value in the first column of the row. String values must
be double-quoted then URL-encoded, for example %22KEY%22
.
POST operations that reference a new key
add rows to the table,
otherwise they modify existing rows.
DELETE operations remove existing rows. The key
is required for
DELETE. Deletions are always per-row, never the entire table.
The action
and table_type
parameters do not apply to POST or
DELETE operations. They only apply to the GET operations enumerated
below (dump
, dump-data-only
, schema
, and subscribe
). All GET
operations besides those four are per-row and require a key
parameter but not an action
or table_type
.
dump
: Reports the full contents of a table, either for astatic
,dynamic
, orrtt
table in read-only format. It does not modify a table’s contents. Leave out the ‘key’ parameter as it refers to a specific table row. Forstatic
tables, the schema is included. If thetable_type
isrtt
, you must include&table_type=rtt
in the URL.dump-data-only
: Reports the full contents of a table as above, but lists the data in a minimal text format. Leave out the ‘key’ parameter as it refers to a specific table row.schema
: Generates a description of the requested table data. Note that this data does not follow the more formal XML or JSON schema format.subscribe
: Generates table metadata up to the current sync point, usually equivalent to the table schema. This only applies todynamic
table types.
The key
required for POST, DELETE, and per-row GET operations. For
other operations, do not specify a key
since the operation returns
the whole table (the key is not omitted but not applicable because the
operation returns the entire table).
The table_type
parameter is only needed if calling dump
or
dump-data-only
on a dynamic table. In those cases, specify
table_type=dynamic
or table_type=rtt
. You can specify
table_type=static
but static
is the default, so it is
optional. These are the only cases where table_type
is needed. This
parameter does not work with POST or DELETE operations.
The table_type
parameter is only needed if calling “dump” or
“dump-data-only” on a dynamic table. In those cases, specify
table_type=dynamic
or table_type=rtt
. You can specify
table_type=static
but static
is the default, so it is
optional. These are the only cases where table_type
is needed.
See the Get Row or Table by Service Instance or Get Row or Table by Product Type operations for samples of this alternative output.
API summary
Operation | Method | Endpoint |
---|---|---|
Service Instances | ||
Get Row or Table by Service Instance | GET | /recursive-dns-db/ |
Add or Update Row by Service Instance | POST | /recursive-dns-db/ |
Remove Row by Service Instance | DELETE | /recursive-dns-db/ |
Product Types | ||
Get Row or Table by Product Type | GET | /recursive-dns-db/ |
Add or Update Row by Product Type | POST | /recursive-dns-db/ |
Remove Row by Product Type | DELETE | /recursive-dns-db/ |
Get row or table by service instance
This operation gets data for a row with a unique service instance
ID. For rows it works on both static and RTT tables. If no rows have a
key column matching this string, an error will be returned. If the key
column is of type STRING, then the key must be enclosed in URL-encoded
double quotes (%22key%22
).
GET /recursive-dns-db/
Example: /recursive-dns-db/
Parameter | Type | Sample | Description |
---|---|---|---|
Required | |||
key |
String | "127.0.0.1" |
The value of the key column to access. If the key column is a string, it must be wrapped with URL-encoded double quotes, such as %22key%22 . |
serviceInstanceId |
Integer | 8739485 |
The service instance ID. |
tableName |
String | TableData-1 |
The table to be queried. |
Optional | |||
action |
String | schema |
The action taking place. The parameters are dump to remove an entire table, dump-data-only to remove only the data found in a table, subscribe to return table metadata up to the current sync point with a service instance ID, or schema to describe the table’s structure. Used with the GET and POST operations. |
table_type |
String | rtt |
Table types may be static , dynamic , or rtt . You can set this parameter to static . The default value is rtt . |
Status 200 application/xml
Response:
<Row>
<Key>127.0.0.1</Key>
<Columns>
<Column>
<Value>127.0.0.1</Value>
</Column>
<Column>
<Value>Utah</Value>
</Column>
</Columns>
</Row>
Status 200 application/json
Response:
{
"Key": "127.0.0.1",
"Columns": [
{ "Value": "Utah" },
{ "Value": "127.0.0.1" }
]
}
The following shows the alternate response format when the action
is
set to schema
or subscribe
. Each field’s Name
is a valid key
with which to access a table row.
<Schema>
<Field>
<Name>HostIP</Name>
<Type>CIDR</Type>
</Field>
<Field>
<Name>SubscriberID</Name>
<Type>STRING</Type>
</Field>
</Schema>
The following shows the alternate response format when the action
is
set to dump
. The MetaData
section and each Field
contain lines
of key/value pairs rather than structured XML. The trailing lines
after the MetaData
section represent the table’s raw data separately
available when the action
is dump-data-only
.
<Schema>
<Field>
Name: MyKey
Type: STRING
</Field>
<Field>
Name: v4Mask
Type: UINT64
</Field>
<Field>
Name: v6Mask
Type: UINT64
</Field>
<Field>
Name: MyVal
Type: STRING
</Field>
<Field>
Name: MyCidr
Type: CIDR
</Field>
</Schema>
<MetaData>
TableType: INDEXED
TableVersion: 6241959731729006595
</MetaData>
"Michelangelo" 32 128 "Donatello" 5.6.7.8/32
"Raphael" 24 96 "Leonardo" 127.0.0.1/32
Add or update row by service instance
The request must specify the row’s data, formatted as XML or JSON. The
optional Expiry
data member is a time interval in seconds after
which the row expires: if no expiry is given, the row does not
expire. This method only applies to RTT tables.
The key
column is matched against the leftmost column in the table.
If it matches an existing row, that row is updated. Otherwise, a new
row is added. Note that key
is considered to be the value of the
leftmost row: thus, the XML or JSON you submit in the body of your
request should not contain a field for the leftmost key column: only
for the subsequent columns.
In the following example the table is assumed to have two columns. The
first one is updated by using the key field, and the second one is a
string column whose new value will be Arizona
.
POST /recursive-dns-db/
Example: /recursive-dns-db/
Content-Type: application/xml
Request:
<Row>
<Columns>
<Column>
<Value>Arizona</Value>
<Type>STRING</Type>
</Column>
</Columns>
<Expiry>60</Expiry>
</Row>
POST /recursive-dns-db/
Example: /recursive-dns-db/
Content-Type: application/json
Request:
{
"Expiry": 60,
"Columns": [
{
"Value": "Arizona",
"Type": "STRING"
}
]
}
Parameter | Type | Sample | Description |
---|---|---|---|
Required | |||
key |
String | "127.0.0.1" |
The value of the key column to access. If the key column is a string, it must be wrapped with URL-encoded double quotes, such as %22key%22 . |
serviceInstanceId |
Integer | 8739485 |
The service instance ID. |
tableName |
String | TableData-1 |
The table to be queried. |
Status 204
Remove row by service instance
This operation lets you delete a row from a table with a service
instance ID. It only applies to RTT tables. The row to be deleted must
have a leftmost key column whose value matches key
.
DELETE /recursive-dns-db/
Example: /recursive-dns-db/
Parameter | Type | Sample | Description |
---|---|---|---|
Required | |||
key |
String | "127.0.0.1" |
The value of the key column to access. If the key column is a string, it must be wrapped with URL-encoded double quotes, such as %22key%22 . |
serviceInstanceId |
Integer | 8739485 |
The service instance ID. |
tableName |
String | TableData-1 |
The table to be queried. |
Status 204
Get row or table by product type
This operation gets data for a row with a unique product name and
contract ID. For rows it works on both static and RTT tables. If no
rows have a key column matching this string, an error will be
returned. If the key column is of type STRING, then the key must be
enclosed in URL-encoded double quotes (%22key%22
).
GET /recursive-dns-db/
Example: /recursive-dns-db/
Parameter | Type | Sample | Description |
---|---|---|---|
Required | |||
contractId |
String | ctr_1-1TJZH5 |
The contract ID. |
key |
String | "127.0.0.1" |
The value of the key column in the row to be returned. If no rows have a key column matching this string, an error will be returned. If the key column is of type STRING, then the key must be enclosed in URL-encoded double quotes (%22key%22 ). |
productType |
String | managed |
The type of RKS. |
tableName |
String | TableData-1 |
The table to be queried. |
Optional | |||
action |
String | schema |
The action taking place in an operation. The parameters are dump to remove an entire table, dump-data-only to remove only the data found in a table, subscribe to return table metadata up to the current sync point with a service instance ID, or schema to describe the table’s structure. |
table_type |
String | rtt |
Table types may be static , dynamic , or rtt . You can set this parameter to static . The default value is rtt . |
Status 200 application/xml
Response:
<Row>
<Key>127.0.0.1</Key>
<Columns>
<Column>
<Value>127.0.0.1</Value>
</Column>
<Column>
<Value>Utah</Value>
</Column>
</Columns>
</Row>
Status 200 application/json
Response:
{
"Key": "127.0.0.1",
"Columns": [
{ "Value": "Utah" },
{ "Value": "127.0.0.1" }
]
}
The following shows the alternate response format when the action
is
set to schema
or subscribe
. Each field’s Name
is a valid key
with which to access a table row.
<Schema>
<Field>
<Name>HostIP</Name>
<Type>CIDR</Type>
</Field>
<Field>
<Name>SubscriberID</Name>
<Type>STRING</Type>
</Field>
</Schema>
The following shows the alternate response format when the action
is
set to dump
. The MetaData
section and each Field
contain lines
of key/value pairs rather than structured XML. The trailing lines
after the MetaData
section represent the table’s raw data separately
available when the action
is dump-data-only
.
<Schema>
<Field>
Name: MyKey
Type: STRING
</Field>
<Field>
Name: v4Mask
Type: UINT64
</Field>
<Field>
Name: v6Mask
Type: UINT64
</Field>
<Field>
Name: MyVal
Type: STRING
</Field>
<Field>
Name: MyCidr
Type: CIDR
</Field>
</Schema>
<MetaData>
TableType: INDEXED
TableVersion: 6241959731729006595
</MetaData>
"Michelangelo" 32 128 "Donatello" 5.6.7.8/32
"Raphael" 24 96 "Leonardo" 127.0.0.1/32
Add or update row by product type
This operation allows you to add or update a row in a table with a product name and contract ID. The optional Expiry data member is a time interval in seconds after which the row expires: if no expiry is given, the row does not expire. This method only applies to RTT tables.
The data in your request should contain the row to be updated or added, in either XML or JSON format (see the following examples). If your table only consists of one row, then the message body for your submit would not contain any columns, since the key field is used as the leftmost column value (see below for more on this).
The key
column is matched against the leftmost column in the table.
If it matches an existing row, that row is updated. Otherwise, a new
row is added. Note that key
is considered to be the value of the
leftmost row: thus, the XML or JSON you submit in the body of your
request should not contain a field for the leftmost key column: only
for the subsequent columns.
In the following example the table is assumed to have two columns. The
first one is updated by using the key field, and the second one is a
string column whose new value will be Arizona
.
POST /recursive-dns-db/
Example: /recursive-dns-db/
Content-Type: application/xml
Request:
<Row>
<Columns>
<Column>
<Value>Arizona</Value>
<Type>STRING</Type>
</Column>
</Columns>
<Expiry>60</Expiry>
</Row>
POST /recursive-dns-db/
Example: /recursive-dns-db/
Content-Type: application/json
Request:
{
"Expiry": 60,
"Columns": [
{
"Value": "Arizona",
"Type": "STRING"
}
]
}
Parameter | Type | Sample | Description |
---|---|---|---|
Required | |||
contractId |
String | ctr_1-1TJZH5 |
The contract ID. |
key |
String | "127.0.0.1" |
The value of the key column in the row to be returned. If no rows have a key column matching this string, an error will be returned. If the key column is of type STRING, then the key must be enclosed in URL-encoded double quotes (%22key%22 ). |
productType |
String | managed |
The type of RKS. |
tableName |
String | TableData-1 |
The table to be queried. |
Status 204
Remove row by product type
This operation lets you delete a row from a table with a product name
and contract ID. It only applies to RTT tables. The row to be deleted
must have a key column (leftmost column) whose value matches key
.
DELETE /recursive-dns-db/
Example: /recursive-dns-db/
Parameter | Type | Sample | Description |
---|---|---|---|
Required | |||
contractId |
String | ctr_1-1TJZH5 |
The contract ID. |
key |
String | "127.0.0.1" |
The value of the key column in the row to be returned. If no rows have a key column matching this string, an error will be returned. If the key column is of type STRING, then the key must be enclosed in URL-encoded double quotes (%22key%22 ). |
productType |
String | managed |
The type of RKS. |
tableName |
String | TableData-1 |
The table to be queried. |
Status 204
Data
This section provides you with the data model for the AnswerX RKS API.
Row
Encapsulates data for a row with either a call to a unique service ID or a call to a product name and contract ID.
For all REST methods (GET, PUT/POST, and DELETE), there are two ways to access your data: instance ID or product type and contract ID. See the Overview for more information.
This object may represent data with both static and RTT or dynamic tables.
Sample JSON response:
{
"Key": "127.0.0.1",
"Columns": [
{
"Value": "Utah"
},
{
"Value": "127.0.0.1"
}
]
}
Sample XML response:
<Row>
<Key>127.0.0.1</Key>
<Columns>
<Column>
<Value>127.0.0.1</Value>
</Column>
<Column>
<Value>Utah</Value>
</Column>
</Columns>
</Row>
Row members
Member | Type | Required | Description |
---|---|---|---|
Key |
String | ✓ | The value of the key column in the row to be returned. If no rows have a key column matching this string, an error will be returned. If the key column is of type STRING, then the key must be enclosed in URL-encoded double quotes (%22key%22 ). |
Value |
String | ✓ | The value of the data to be returned. |
Schema
Encapsulates the schema for a table with either a call to a unique
service ID or a call to a product name and contract ID. Applies in GET
operations when the action
is set to schema
or subscribe
. This
object only applies to dynamic tables.
Sample JSON response:
{
"Field": [
{
"Name": "HostIP",
"Type": "CIDR"
},
{
"Name": "SubscriberID",
"Type": "STRING"
}
]
}
Sample XML response:
<Schema>
<Field>
<Name>HostIP</Name>
<Type>CIDR</Type>
</Field>
<Field>
<Name>SubscriberID</Name>
<Type>STRING</Type>
</Field>
</Schema>
Schema members
Member | Type | Required | Description |
---|---|---|---|
Name |
String | ✓ | The name of the column. |
Type |
Enumeration | ✓ | The type of data. The allowed types are INT , UINT64 , STRING , or CIDR . |
Errors
If you encounter a variety of errors, the AnswerX RKS API responds with the appropriate HTTP status codes and a response object that explains them, as shown here. There are many possible causes for failure, such as malformed JSON or XML code or missing fields. Note that the error responses are in JSON format, even if the Accept header is set to XML.
JSON problems
The Akamai API platform returns HTTP Problem error objects. For example:
{
"type": "https://problems.luna.akamaiapis.net/-/pep-authn/request-error",
"title": "Bad request",
"status": 400,
"detail": "Authorization header missing",
"instance": "https://akab-xxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxx.luna.akamaiapis.net/recursive-dns-db/v1/locations",
"method": "GET",
"serverIp": "NNN.NNN.NNN.NNN",
"clientIp": "NNN.NNN.NNN.NNN",
"requestId": "xxxxxxxx",
"requestTime": "2015-04-16T14:56:52Z"
}
In most cases, the type
and title
provide enough information to
understand the nature of the error.
Please be sure to reference the problem type when communicating with Akamai representatives or the Akamai Developer Community.
Error responses
This API produces the following set of HTTP status codes for both success and failure scenarios:
Code | Message | Description |
---|---|---|
200 | Successful request | The actual response will depend on the request method used. In a GET request, the response contains an entity corresponding to the requested resource. In a POST request, the response contains an entity describing or containing the result of the action. |
204 | No content | The server successfully processed the request and is not returning any content. |
400 | No Verb Provided | No action verb was provided in the request, and the request type requires one. |
400 | Request has invalid URL | The format of the REST URL was incorrect. See the Overview for correct format examples. |
400 | Request has unknown verb | An action verb was provided, but not one of “schema”, “subscribe”, “dump”, “dump-data-only”. |
400 | No Table Provided | No table name was given. |
400 | Could not parse POST data | The contents of a POST (XML or JSON) could not be parsed. |
400 | No Key Provided | The request requires a key, but none was given. |
400 | Unexpected first line from RKS | The request triggered an unknown response from RKS. |
400 | Missing table name | No table name was given. |
400 | Missing row key | The request requires a key, but none was given. |
400 | POST error | The POST data was parsed successfully, but RKS did not accept it. |
400 | RKS error: bad command or invalid JSON/XML | The command was invalid, or the JSON/XML was not accepted by RKS. |
403 | User ID <ID> does not have access to customer ID <ID> | The Portal user who made the request is not allowed to access the given customer’s data. |
404 | Unexpected reply from RKS | RKS returned an unrecognized response to a row query. |
404 | No row for key | No row was found matching the given key. |
404 | RKS error: Table <TABLE> not found | The table was not found in the API system. |
404 | RKS error: Key <KEY> not found | No row was found matching the given key. |
405 | Request <REQ> is forbidden (neither GET, PUT/POST, nor DELETE) | The request did not use one of the allowed HTTP methods. |
405 | Method not allowed for request type (only POST or PUT are allowed) | The request type requires POST or PUT, but a different method was used. |
406 | Accept header allows neither JSON nor XML | The Accept header in the request was set to a value other than XML or JSON. |
429 | Customer <CUST> has hit request limit <LI>> for past minute | The given customer’s API tables have received more than the allowed number of requests in the past minute. This is a rate-limiting feature to protect against DDOS attacks. The condition will clear after the minute has elapsed. |
500 | Failed to create JSON for table <TABLE> schema | The AnswerX RKS API was not able to parse a table schema from the API (JSON). |
500 | Failed to create XML for table <TABLE> schema | The AnswerX RKS API was not able to parse a table schema from this API (XML). |
500 | Failed to connect to any RKS | The AnswerX RKS API was not able to connect to an API table server for the customer. |
500 | Failed to connect to start TLS | The AnswerX RKS API was not able to create a TLS session to the API. |
500 | Secure session is not valid | The AnswerX RKS API was not able to create a secure session with the API. |
500 | Schema pull: field missing name or type | The AnswerX RKS API returned a schema that is missing a type of name for a field. |
500 | RKS Connection internal server error | An internal error prevented the API from talking to the AnswerX RKS API. |
502 | RKS error: No data returned | No data was returned by the AnswerX RKS API to this API. |
502 | No lines returned from RKS | No table lines were returned by the AnswerX RKS API to this API. |
502 | Schema pull: failed to read to end of schema | This API returned part of a schema, but not the whole thing. |
502 | Bad RKS response: <CODE> | RKS did not return the expected response code to this API. |
502 | RKS Connection timed out | The connection to this API timed out before all data was sent. |
502 | RKS Connection network error | The connection to this API experienced a network error. |
502 | RKS Connection refused | The connection to this API was refused. |
502 | RKS Connection reset | The connection to this API was reset. |
502 | RKS Connection internal server error | The connection to this API failed due to an internal RKS error. |
502 | Bad HELO from RKS | RKS failed to return a HELO to this API. |
502 | Static ID to RKS failed | RKS failed to return a static ID. |
502 | RKS error: failed to fetch row | RKS failed to return a row to RKSAPI. |
502 | Cannot parse ID line from RKS | This API was not able to parse the RKS ID line. |
502 | Cannot parse session ID from RKS | This API was not able to parse the RKS session ID. |
502 | Cannot parse byte count from RKS | This API was not able to parse the RKS data byte count. |