API support: tech@avata.gg

This API is used to communicate with the Avata services.

NFT flow sequence diagram

.. Booking flow

Digital Assets flow sequence diagram

This section describes the different calls that can be made for policy requests

This section describes the authentication process and calls. The authentication process consists of two steps.

• Step one is requesting a nonce. The nonce can be used to sign the authentication request.
• Step two is requesting authentication which responds with a JWT authentication token.

Authenticate flow sequence diagram



The authentication JWT token is required for the Policy and Claim requests. For these requests also the API key is required.

This section describes the different calls that can be made for policies.

This section describes the different calls that can be made for claims.

NOTE: If a policy report will be uploaded this must be done in front of the create claim call. The upload call will respond with a key of the claim document file. This key must be added in the create claim call.

This section describes the different calls that can be made for KYC.

The Avata API supports callbacks to the merchant. The callback is triggered when a resource is updated. The callback is triggered with a POST request to the callback URL of the merchant. The body of the request contains a JSON object with the following structure:

Field	Type	Description
eventType	string	The type of event that triggered the callback.
body	object	The body of the event.

The eventType can be one of the following values:

eventType	Description
policy-update	The policy is updated.
claim-update	The claim is updated.

Policy Updates The body of the policy-update event is an object with the following structure:

Field	Type	Description
status	PolicyStatus	The status of the policy.
uuid	string	The uuid of the policy.
reference	string	The reference of the policy.
details	PolicyDetails	The details of the policy.

The PolicyDetails object has the following structure:

Field	Type	Description
policyId	string	The id of the policy.
policyType	string	The type of the policy.
startDateTime	string	The start date and time of the policy.
endDateTime	string	The end date and time of the policy.

The PolicyStatus object has the following structure:

Field	Type	Description
CREATED	string	The policy is created.
PENDING	string	The policy is pending.
EXPIRED	string	The policy is expired.
SEND	string	The policy is send.
ACCEPTED	string	The policy is accepted.
REJECTED	string	The policy is rejected.
ERROR	string	The policy has an error.
RETRYING	string	The policy is retrying.

The following example shows the body of a policy-update callback request:

{
  "eventType": "policy-update",
  "body": {
    "status": "APPROVED",
    "uuid": "d7b9f5b0-4b4b-11eb-ae93-0242ac130002",
    "reference": "1234567890",
    "details": {
      "policyId": "1234567890",
      "policyType": "DIGITAL_ASSET",
      "startDateTime": "2021-01-01T00:00:00.000Z",
      "endDateTime": "2021-01-02T00:00:00.000Z"
    }
  }
}

Claim Updates

The body of the claim-update event is an object with the following structure:

Field	Type	Description
status	ClaimStatus	The status of the claim.
uuid	string	The uuid of the claim.
policyUuid	string	The uuid of the policy.
details	ClaimDetails	The details of the claim.

The ClaimDetails object has the following structure:

Field	Type	Description
claimId	string	The id of the claim.

The ClaimStatus object has the following structure:

Field	Type	Description
CREATED	string	The claim is created.
PENDING	string	The claim is pending.
REPORTED	string	The claim is reported.
REVIEWED	string	The claim is reviewed.
REJECTED	string	The claim is rejected.
APPROVED	string	The claim is approved.

Callback request example

The following example shows the body of a claim-update callback request:

{
  "eventType": "claim-update",
  "body": {
    "status": "APPROVED",
    "uuid": "d7b9f5b0-4b4b-11eb-ae93-0242ac130002",
    "policyUuid": "d7b9f5b0-4b4b-11eb-ae93-0242ac130002",
    "details": {
      "claimId": "1234567890"
    }
  }
}

Merchant Claim Page Guide

To direct your clients to the Merchant Claim Page, you need to construct a specific URL that includes necessary parameters. The structure of the URL is as follows:

https://portal.avata.gg/merchant-claim/{policyUuid}/{signedPolicyUuid}

In this URL:

• {policyUuid} should be replaced with the specific policy UUID you want the client to access.
• {signedPolicyUuid} should be replaced with a message that includes the policyUuid, signed with the private key of the owner's wallet.

Understand the Parameters

Detailed information about the parameters in the URL:

1. policyUuid

   This is a unique identifier assigned to each policy in our system.

2. signedPolicyUuid

   This is a message encrypted with the private key of the owner's wallet. This message should include the policyUuid. This is a crucial component as it allows us to verify the transaction with the owner's address.

Signing signedPolicyUuid

To generate the signedPolicyUuid, you need to follow the process of signing a message with the private key of the owner's wallet. It involves encrypting the policyUuid with the owner's private key. An example in Node.js:

var ethers = require('ethers');

const wallet = new ethers.Wallet.createRandom();

const message = "policyUuid";
const signature = await wallet.signMessage(message);

To direct your clients to the Merchant Claim Page, you need to construct a specific URL that includes necessary parameters. The structure of the URL is as follows:

https://portal.avata.gg/merchant-claim/{policyUuid}/{signedPolicyUuid}

In this URL:

• {policyUuid} should be replaced with the specific policy UUID you want the client to access.
• {signedPolicyUuid} should be replaced with a message that includes the policyUuid, signed with the private key of the owner's wallet.

Detailed information about the parameters in the URL:

1. policyUuid

   This is a unique identifier assigned to each policy in our system.

2. signedPolicyUuid

   This is a message encrypted with the private key of the owner's wallet. This message should include the policyUuid. This is a crucial component as it allows us to verify the transaction with the owner's address.

To generate the signedPolicyUuid, you need to follow the process of signing a message with the private key of the owner's wallet. It involves encrypting the policyUuid with the owner's private key. An example in Node.js:

var ethers = require('ethers');

const wallet = new ethers.Wallet.createRandom();

const message = "policyUuid";
const signature = await wallet.signMessage(message);