About HTTP Model

Scope

For all of Global Travel Rule service, We can separate to two different common HTTP response structures:

• For common requests

Where the spec cover for: HTTP Request / HTTP Response / HTTP Callback.

For Common HTTP Model, all HTTP status code will follow the actual situation (400 Bad Request, 500 Internal Server Error, 403 Permission denied, etc.). It will still use the following structure.

Common Success/Error Structure

For Normal Success Result:

{
    "code": "0",
    "msg": "success",
    "data": { ... }
}

For Error Result:

{
    "code": "-1",
    "msg": "failed",
    "data": { ... }
}

More about error codes, please see:

ResponseStatusEnum

Travel Rule HTTP Model

Travel Rule HTTP Model is used for specific scenarios like submit before-on-chain, submit after-on-chain, but does not include login or list-vasp.

The HTTP status code under the scope uses 200 HTTP OK. If you or the GTR respond with a code that is not 200, it means there is an unexpected error during verification, which could force the transaction to be canceled.

Server Submit

When you invoke submit and verify related API requests for interacting with another VASP via GTR server (e.g., submit before-on-chain, submit after-on-chain), the Travel Rule HTTP Model is used for consistency. (Including Callback Response, we will discuss below)

{
    "verifyStauts": 100000,
    "verifyMessage": "success",
    "data": { ... }
}

Please note that verifyStatus is using Integer type, and verifyMessage could depend on different situations and will have different results.

{
    "verifyStauts": 100001,
    "verifyMessage": "failed",
    "data": { ... }
}

More about error codes, please see: VerifyStatusEnum

Callback Response

Common Callback Response follows the structure:

{
    "verifyStauts": 100000,
    "verifyMessage": "verify success",
    "data": { ... }
}

The callback is responded to by you, and you need to check the data field. The data could be the info required by the solution from another VASP invoked, and verifyStatus is a general determinant, verifyStatus can be used in any field that returns the status of the invocation. For example, in before-on-chain scenario, if someone invoke to let you verify the address first, that you could reply as:

{
  "verifyStauts": 100000,
  "verifyMessage": "address is exists"
}

Or if the data does not exists, a common response will be:

{
  "verifyStauts": 300004, // or 100001 for common failed
  "verifyMessage": "data not found"
}

The verifyMessage is a custom field where you can provide the details of the status.

More about error codes that you could use in the callback response, please refer to: VerifyStatusEnum