The following shows the standards we expect for an API endpoint that our loyalty rules interact with (e.g. to get off-chain data from your system that somehow impacts rule evaluation and/or rewards).

Configuration

For our system to be able to call your endpoint(s) during rule execution we ask for the following:

• Endpoint URL
• API key
• Standard pagination & sorting parameters

Authentication

Please build your APIs with API key access. Allow us to pass in the API key as a header

# we will send the following header on all requests
x-api-key: YOUR_API_KEY

Endpoint Design

• Our system will use this endpoint to fetch data for relevant users each time the related loyalty rule(s) are executed/evaluated
  • Note: this is why the walletAddress request parameter shown below must support both a single wallet address (provided as a string) and multiple (provided as an array)
• This endpoint will be called many times; please make sure it is performant and can handle the load
• For non-existant/not-found wallet addresses please don’t include them in the response array or pass back a null data[i].data value

GET <URL can be specified, e.g. https://api.domain.com/route>

Request parameters:
{
  walletAddress: string | string[],  // case-insensitive
  startingAfter?: string // optional, only if pagination is required.
}

// no pagination
Response body:
Status code: 2**

{
  "data": [{
    "id": string // optional, only if pagination is required
    walletAddress: string
    data: object // important: this contains the data properties relevant for rule evaluation/rewards distribution
  }],
  hasNextPage: boolean // if pagination is required
}