Covalent

# Introduction

The Covalent API facilitates various use cases for Loyalty Commerce. Our API allows our Partners to:
 - Manage Loyalty Currencies in the Cloud
 - Access Popular Loyalty Currencies from other Brands
 - Sell and Distribute your Loyalty Currency to Partners
 - Issue, Transfer, Redeem, or Exchange any loyalty currency via API
 - Pull Transaction History Details into 3rd Party Platforms
 - Enable the Exchange of Loyalty Currencies into Gift Cards and other Redemption Products in many fiat currencies
To benefit from the Covalent platform, you do not need to use all of these features. While there are many Endpoints for specific use cases, most Partners end up using only a few Endpoints.

# Architecture
The Covalent API is organized around REST. Our API has predictable resource-oriented URLs, accepts JSON-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.

Calls to the API have to be properly authenticated using your public and secret API keys. The keys are available in the 'CREDENTIALS' section of the "Loyalty API" module in the Management Dashboard. These keys MUST never be exposed to the public or any unauthorized person.

The API is designed for a server to server communication. If you want to communicate with the API from a client it must be through a server environment, to protect the integrity of the requests and the API keys, and not expose them on front-end platforms.

# Authentication
The API authenticates every request based on two elements - Credential and Signature. Every request must include an `Authorization` header with the following two elements.
`Credential=<public-key>, Signature=<calculated-signature>`

## Credential
In this parameter, the API requires you to provide the `<public-key>` that is unique to your account. Your keys are available in the 'CREDENTIALS' section of the "Loyalty API" module in the Management Dashboard.

## Signature
### How is the Signature calculated?
  The signature is a [HMAC-SHA256](https://en.wikipedia.org/wiki/HMAC) hash in hexadecimal of the request content, using the `private_key` as the key.
  Keep in mind that the string you use to generate the signature and the string you send to the API has to be exactly the same. This includes newlines and spaces. If you compress the JSON body of your request, after generating the signature, the request will be rejected.

### POST/PUT/PATCH HTTP methods
  These types of requests use the string representation of the body to calculate the signature.

  For example, for the request with body: `{"foo": "bar"}` the signature calculated using `sec_12345` as the private key would be `4d84ba663b9c6179dd98023087da5baa8a4e3eb59ba45284935261350ba70742`

### GET HTTP method
  This type of request uses the query string to calculate the signature. Take into account that the "?" character must not be included while calculating the signature.

  For example, for the request with query string: `?foo=bar` the signature calculated using `sec_12345` as the private key would be `88d64dfcb542c35dc22bae059bd5f5a5d038572a7b391dfc4cd5f3a5530c1760` which is the hash for the string "foo=bar"

  To generate the signature of a GET request without any parameters, simply encode an empty string.

# Security
The API uses asymmetric cryptography to authenticate requests using the API keys we provide. This provides the following assurances:
  - **Requester identification:** Every request requires your public key to be sent, in conjunction with a signature generated with your secret key.
  - **Protection against man-in-the-middle (MITM) attacks:** The request signature is calculated using the body of the request, which means that any request that has been tampered with during the transport will be rejected by the Covalent platform, since the signature received will not match the request contents.

The API only supports requests over HTTPS.

# Idempotency
The API supports [idempotent](https://en.wikipedia.org/wiki/Idempotence) requests to safely retry requests without having to worry about doing the same operation more than once.
For example, if there's a connection error generating a gift card, you can retry the request with the same idempotency key without having to worry about creating multiple gift cards.

To send an idempotent request, include an additional `Idempotency-Key: <key>` header in the request. An Idempotency Key `<key>` is a unique identifier generated by the client with a length between 1 and 255 characters. While this can be any type of unique key, we recommend a UUID to avoid collisions. An Idempotency key expires 8 hours after the initial request.

In a repeated request the response will always have the response body of the original request, along with the same status and `400` errors, if any. The response will also include the header `Idempotency-Repeated: true`. In the rare instances where a request is repeated while the first one has not been completed yet, the API will respond with a `409 - Conflict` status.

The API supports idempotency on POST and PATCH requests. Since GET, PUT and DELETE are idempotent by default, the `Idempotency-Key` header will be ignored.


# Key fields
Covalent acts as a connectivity bridge between various partners using its standardized APIs and interface, hence, shielding each partner from the complexity, nuances, and customizations of hundreds of loyalty systems and merchant partners. However, the interacting partners need to have a common reference for a transaction in their own system for easy reconciliation as well as for customer support purposes.
In this section, you will find information on some key fields and attributes that are used through our API and on different objects. This information will help you understand how to use these key fields.

## External Reference
The field `external_reference` is used for each transaction request to provide a unique identifier from your system that can be used as a reference during the reconciliation process. This could be a GUID, internal transaction identifier, invoice number, booking number, itinerary number, or any other unique number in your system that can be used to uniquely identify the action. Even though this is not a required field, it is strongly recommended that you provide value in this field.

## Loyalty System Id
The field `loyalty_system_id` is returned by our system on each transaction and it provides the unique identifier in the partner loyalty system. This ID is not generated by Covalent but is provided by the partner loyalty program and hence could be used as a common field for reconciliation between your system and the partner's system.

## Loyalty System Data
Sometimes, a loyalty program requires you to send some additional data to connect. For example, user_id, application_id, partner_code, etc. You will be able to provide the data in this field for all the transactions with the partner loyalty program. To check if and what additional data is required by the partner loyalty program, refer to the Partners Endpoint.


# Common Use cases
Our API can be used for numerous Loyalty Commerce use cases. Some of the most common use cases are mentioned below along with the information on which Endpoints to use for each use case. There are auxiliary Endpoints that could be used to enhance your integration and customer experience. For example, you could pull all transaction history out via the API into your Business Intelligence or data staging environments or you could validate the member details before issuing Loyalty Currency Units.

## Accrual/Issue/Top-up
The underlying objective of this use case is to “give Loyalty Currency Units to a member” for one reason or another. The reason could be a purchase of a product, their birthday, completion of a survey, referral, customer service issue, etc. Furthermore, you may want to give the member units of your own Loyalty Currency or one of your Partners’ Loyalty Currency.

You should use Accruals Endpoints for this use case. There are three Endpoints that can be used for issuing your or a Partner’s currency. You can use any one of the Endpoints or a combination of them to issue Loyalty Currency Units to the member.

### Direct Accruals
This Endpoint is to be used when you know the exact number of Loyalty Currency Units to give to a member. In this scenario, you are calculating the number of Loyalty Currency Units in your environment and providing the exact number of units in the endpoint.

### Purchase Rules
This Endpoint is to be used when you would like to give the number of Loyalty Currency Units based on Purchase Rule(s) defined in the Covalent system. For example, giving points worth 1% of the fiat transaction amount. In this case, your application does not need to know how to calculate the number of Loyalty Currency Units or even the cost of the Loyalty Currency Units in any of your Partners' programs.

### Activity Rules
This Endpoint is to be used when you would like to issue the number of Loyalty Currency Units based on pre-defined Activity Rule(s) in the system. For example, you might offer 200 points for posting a product review or referring a friend.

## Currency Exchange
Our API provides tools for quick collaboration among brands to enable their respective members to exchange loyalty units between programs. The exchange could be one-way only, or both directions – in and out – of the programs. Use the Loyalty Currency Exchange Endpoints to implement this use case. There are 2 Endpoints that can be used to enable exchange between partners.

### Simulate an exchange
This Endpoint allows you to simulate how many Loyalty Currency units the member would receive of a Partner’s Loyalty Currency in exchange. This can be used to show the member how many points in one or more programs they could get if completing the exchange.

### Execute an exchange
This Endpoint allows you to comlete the exchange Loyalty Currency units to the Partner’s Loyalty Currency.

**Tip:** You could use the Partners Endpoints to get the list of Exchange Partners and automatically display the fields required for each program to complete the exchange. This will be necessary for loyalty programs that require more member validation fields than just the membership number.

## Redemption/Pay with Points
Our Redemption Endpoints have standardized the redemption process across various types of loyalty programs and underlying loyalty systems. This shields you from needing to understand the underlying complexity to integrate into a new loyalty system or modifying the existing integration for a different set of parameters for a new partner.

You should use Standard Redemption Endpoints for this use case. There are four Endpoints that can be used for allowing a Partner’s Loyalty Currency as a form of payment. You can use any one of the Endpoints or a combination of them depending on your customer journey. Although not necessary, we highly recommend you use the  “Lookup a Member” Endpoint to validate if the member exists and if they have enough balance to complete the payment before submitting the payment transaction.

Strictly speaking, Loyalty Exchange and Exchange for Gift Cards are also redemptions, but we provide explicit Endpoints for those actions due to the very high occurrence of those use cases in the industry. Standard Redemptions refers to any other redemptions where the Partners have allowed the member to redeem (exchange) their Loyalty Currency Units for your Products and Services. The products and services may range from flower delivery to booking a trip, buying an insurance plan, topping up their mobile plan, paying at a restaurant, buying concert tickets, or even applying points toward the purchase of a car.

### Simulate a Redemption
To simulate the redemption action and provide information to the member such as the number of points required to complete the action, cancellation allowed, etc. without actually deducting the points from their balance or completing the transaction.

### Execute a Redemption
Deduct points from the member’s account in exchange for the product or service offered.

### Adjust a Redemption
If allowed by the Partner, you may use this Endpoint to notify of any modification in an already completed Redemption. The system will automatically identify if more points are to be redeemed or points are to be refunded to the member.

### Cancel a Redemption
If allowed by the Partner, you may use this Endpoint to cancel an already completed Redemption to refund the points.


API Reference

Direct Accruals Endpoint is to be used in the scenarios where you know in advance the exact number of loyalty currency units that are to be issued to a member and from which account if multiple accounts are available.


Direct Accruals

This Endpoint allows you to create a standard direct accrual in the member’s account. This Endpoint will automatically create a transaction with type “Accrual” in the system.


Execute an accrual

The Purchase Endpoints allows you to simulate or execute a purchase rule to issue loyalty currency units to your members. The purchase loyalty rules can be defined in the following section in the Management Dashboard:

Loyalty Rules > Purchase Rules


Purchase Rules

Simulates the rules to identify the number of Loyalty Currency Units to be given to the members based on the purchase of a product. This Endpoint is used in scenarios where one might want to show the user how many units of the Loyalty Currency will be given for a corresponding action. For example, if user buys a particular item then how many Currency units will be issued. This does not result in issuance of Currency units or execution of a transaction in the system, it is only a simulation.


Simulate a purchase

Trigger the loyalty rules matching the purchase from the specified member.


Trigger a purchase

This Endpoint allows you to retrieve information about a specific purchase rule execution.


Retrieve a purchase rule execution

This Endpoint allows you to retrigger purchase rule(s) if the purchase order in your system has been updated. This is only available if the original transaction is in `pending` status.
An example where this Endpoint is used is when points are issued to a member for a hotel booking but it is pending for a future date. Before the future date is reached, if the member changes the underlying hotel booking, this endpoint would retrigger the purchase rules based on the new booking information.


Retrigger a purchase rule execution

This Endpoint allows you to cancel the transaction(s) made previously during the execution of purchase rule(s). This is only available if the original transaction is in `pending` status.
An example where this Endpoint is used is when points are issued to a member for a hotel booking but it is pending for a future date. Before the future date is reached, if the member cancels the underlying hotel booking, this endpoint would cancel the pending transaction(s).


Cancel a purchase rule execution

The Activities Endpoints allows you to simulate or execute an activity rule to issue loyalty currency units to your members. The activity loyalty rules can be defined in the following section in the Management Dashboard:

Loyalty Rules > Activity Rules


Activity Rules

Simulates an execution of an activity rule for the specified Loyalty Currency. This Endpoint is used in scenarios where one might want to show the user how many units of the Loyalty Currency will be given based on certain activity. For example, if user buys a particular item and shares it on social media then how many Currency units will be provided for that activity. This does not result in issuance of Currency units or execution of a transaction in the system, it is only a simulation.


Simulate an activity rule

Trigger activity rules for the specified Loyalty Currency.


Trigger an activity rule

The Exchange Endpoints enables you to allow your members to exchange their Loyalty Currency Units with your partners' Loyalty Currency Units. You can have a different Exchange Partnership with each Exchange Partner, where you could allow exchange IN or OUT of your currency. The exchange price and other settings are established during the Exchange Partnership set up in the Management Dashboard.

Note that the currencies to be exchanged could be present in different regions and fiat currencies. Covalent will do the currency conversion for the fiat currencies based on the mid-day exchange rate between the fiat currencies.


Exchanges

This Endpoint is typically used in scenarios where you'd want to show to your member that how many units of other currency they would get in exchange for your Loyalty Currency Units or vice versa. For example, if you allow a user to select the number of units of your Loyalty Currency to exchange with your partner's Loyalty Currency, you can use this Endpoint to dynamically show how many units of your partner's Loyalty Currency will be provided to the user for the selected number.

You can send a specific Loyalty Currency as a destination to identify the number of units of that specific Loyalty Currency. Or you could send the destination Loyalty Currency as null and the system will return the array with the exchange result for all the Exchange Partners’ Loyalty Currencies.

Note that the member information is not mandatory but is highly recommended to be input as the exchange price/cost might be dependent on the member attributes.


Simulate currency exchange

This Endpoint is used to exchange Loyalty Currency Units with your partner’s Loyalty Currency Units. The prerequisite is that an Exchange Partnership is already established in the Management Dashboard and the price is set up accordingly. This Endpoint will automatically create two transactions with type "Member Exchange" in the system.

- Origin Member to the Partner account using the origin Loyalty Currency
- Partner account using the destination Loyalty Currency to the destination member

DO NOT USE the "Create a transaction" Endpoint to try to execute this scenario.


Execute currency exchange

Member Endpoints can be used to create a new member, look up information on a member, retrieve a member's details to your system, or update any member's details. Only the Currency Owner i.e. the loyalty program to which the member belongs has access to create a member or update a member.

The Partners could look up a member to confirm if the member exists, check the member account balance, or other details of the member record based on permissions granted by the Currency Owner.

Covalent has standardized these Endpoints and orchestrates the calls to various Loyalty programs to validate a member, get member details, etc. if the Covalent platform is not the primary data store for the relevant loyalty program.

## The Member object
The Member Object represents a member record. For the loyalty programs where Covalent is not the primary data store for their members, the system will connect with the loyalty program system to fetch the member information and present it in the following format.
<SchemaDefinition schemaRef="#/components/schemas/Member" showReadOnly={true} showWriteOnly={true} />


Members

This Endpoint is only accessible by Currency Owners to create a member record if Covalent is the main points bank i.e. the single source of truth for the loyalty program.

Each member object is associated with one loyalty currency. Thus, the same person associated with two different loyalty programs would have two member objects, each with a different corresponding loyalty_program_identifiers and loyalty_currency.

An important attribute is returned in all successful responses - `loyalty_program_identifiers`, which is a unique internal identifier for a member object across the entire Covalent platform.


Create a member

This Endpoint allows you to update the information of an existing member. This Endpoint is only accessible by Currency Owners to update a member record in Covalent.


Update a member

This Endpoint allows you to validate a member and get member details including balance and tier if provided access by the Currency Owner. Where Covalent is not the Main Points Bank, the system will call the Loyalty Program to validate if the member exists, conditional upon if this option is available from the Currency Owner.


Lookup a member

Conversions

This Endpoint is used to convert any fiat currency into a loyalty currency. If the underlying fiat currency of the loyalty currency is different than the requested fiat currency, Covalent will do the currency conversion for the fiat currencies based on the mid-day exchange rate.

An example scenario where this Endpoint is used is when an Issuing Partner may want to offer Currency units worth a specific amount of economic value to a member, but they don´t know how many units of a destination currency can be obtained for that amount of fiat currency.  For example, if a partner wants to give 2.43€ worth of value, they can submit that amount via this Endpoint with the desired destination currency and obtain the maximum number of units in that destination currency that can be obtained with 2.43€


Convert fiat to loyalty currency

Redemptions are referred to as any action that allows the members to redeem the value of their Loyalty Currency Units in exchange for any product, services, or any other redemption options. Standard Redemption Endpoints provides a standardized way for you to allow members to redeem their Loyalty Currency Units for any type of product or service that is not a Gift Card or an Exchange into another loyalty program’s Loyalty Currency.

Standard Redemptions are any redemptions where the Partners have allowed the member to redeem (exchange) their Loyalty Currency Units for your Products and Services. The products and services may range from flower delivery to booking a trip, buying an insurance plan, topping up their mobile plan, paying at a restaurant, buying concert tickets, or even applying points toward the purchase of a car.

The Partners define in the Partnership Settings that the members can redeem their points in various product and service categories. Thus, it is very important that you provide information about the product and services in the request message. If you don’t have defined product categories and details, simply send “General” in the 'category' field.

Some Partners may allow an option to cancel or modify the redemption. This information is provided in the response messages of the Endpoints for you to inform the member before completing the redemption.


Standard Redemptions

This Endpoint is used in scenarios where one might want to simulate the redemption of Loyalty Currency Units for a product or a service without actually completing the transaction. This can be used to show a member how much it would cost in points for the products or services. For example, if a member would like to redeem points for a hotel booking, cab ride, shoe purchase, spa treatment, or any other product/service, this Endpoint would be used to calculate how many Loyalty Currency Units would be required as a form of payment for the product/service.

You can send a list of products and services along with the amount or the price to identify the Loyalty Currency Units required to be redeemed for each type of product or service. The amount, or the price, can be provided either in units in the field "loyalty_amount" or in fiat currency in the field "fiat_amount". It is highly advisable to send the information as well as the member information as the redemption value per Loyalty Currency Unit may depend on any of these factors. For example, a Gold member may require a fewer number of Loyalty Currency Units than a Bronze member to redeem in exchange for a hotel booking whereas booking a cab ride may not depend on the member tier.

The response will contain the total amount in fiat currency and total number of Loyalty Currency Units required for this redemption. If the member information is sent then the response will also provide additional information such as their available balance in Loyalty Currency Units and fiat value of those Loyalty Currency Units for General product if the member does not have sufficient balance to complete this redemption. Additional information in the response would be whether the Currency Owner allows adjustments and cancellations of Redemptions or not.


Simulate a redemption

This Endpoint is used to complete the exchange of Loyalty Currency Units for a product or a service. This Endpoint will automatically create a transaction with type "Redemption" in the system.

It is mandatory to provide the information regarding the product or the service as the redemption value per Loyalty Currency Unit may depend on any of these factors. For example, a Gold member may require fewer number of Loyalty Currency Units than a Bronze member to redeem in exchange for a product. If you are not sure of the product category, then send "General" as the default option.The amount can be provided either in units in the field "loyalty_amount" or in fiat currency in the field "fiat_amount".

The response will contain the total amount in fiat currency and total number of Loyalty Currency Units required for this redemption. The response will also provide additional information such as whether the Currency Owner allows adjustments and cancellations of Redemptions or not.


Execute a redemption

Some Currency Owners may allow for adjustments or even a full refund on an existing Redemption. This Endpoint is used to adjust or modify an already made redemption. For example, if there is a change in redemption product or invoice where the customer has added or removed some products or the quantity, thus, resulting in a different fiat_amount, this Endpoint will be used to reflect the new state of the redemption and refund/redeem points accordingly.

The input request structure remains the same as "Execute a Redemption". You should send all the information regarding the products or the services as per the new updated redemption including the products and services that have not been changed. The system will automatically identify the changes and make adjustments accordingly.

This Endpoint will update the status of the original Redemption transaction as "Adjusted" and will create a new transaction of type "Redemption" and sub-type "Adjustment".


Adjust a redemption

This Endpoint allows you to cancel a specific Redemption. A Redemption can only be canceled if the Currency Owner allows such an action. Simulate a Redemption provides the information whether the cancellation is allowed or not.

This Endpoint will update the status of the original Redemption transaction as "Cancelled" and will create a new transaction of type "Redemption" and sub-type "Cancellation".


Cancel a redemption

These Endpoints are used for redemption via Gift cards. These Endpoints could be used to retrieve a particular Gift Card, to retrieve a list of enabled Gift cards, to simulate an exchange of currency units for  a Gift card, to exchange currency units for a Gift card, or to redeem a custom Gift card. The gift card exchange feature for the loyalty currency must be enabled in the following section of the Management Dashboard:
  *Redemptions > Gift Card Management*

There are two objects in the system that represent a Gift card - GiftCard Object and GiftCardCode Object. GiftCard Object represents the general characteristics of the Gift card whereas GiftCardCode Object represents the characteristics that are specific to the Gift card issued to a member.

For example, if a currency owner enables Starbucks gift card through the Management Dashboard there will be a GiftCard Object in our system that would represent general details of Starbucks cards including the possible denominations of let's say $5, $10, $15, $25. When a member exchanges their points for a Starbucks gift card, the system will create a GiftCardCode object specific for that member with specific information such as the value of the Gift card ($5).

## The Gift Card object
GiftCard Object represents a Gift card that could be used for redemption of Loyalty Currency units via Gift cards. It contains the details of the general characteristics of the Gift card. Note that it doesn't represent an issues/redeemed Gift card but only the general characteristics. Once a Gift card is issued GiftCardCode Object provides the details specific to the Gift card for the member. It has the following attributes:
<SchemaDefinition schemaRef="#/components/schemas/GiftCard" showReadOnly={true} showWriteOnly={true} />

## The Gift Card Code object
GiftCardCode Object represents the code details for the issued Gift card. It contains information specific to the Gift card issued to the member. For example, in general, Starbucks Gift cards could be of any one of denominations of $5, $10, $25, $50. This Object will provide the exact amount of the Gift card that was issued to the user. It has the following attributes:
<SchemaDefinition schemaRef="#/components/schemas/GiftCardCode" showReadOnly={true} showWriteOnly={true} />


Gift Cards

This Endpoint can be used to retrieve the list of gift cards that have been enabled in the following Management Dashboard section:

*Redemptions > Gift Card Management*


Retrieve the list of enabled gift cards

Returns the general characteristics and details of the specified gift card.
The Gift card exchange feature for the loyalty currency must be enabled in the below mentioned section of the Management Dashboard to be able to retrieve information about the Gift card.

*Redemptions > Gift Card Management*


Retrieve a gift card

This Endpoint is used in scenarios where one might want to simulate an exchange of Loyalty currency units for a Gift card without actually issuing the Gift card. For example, if a member wants to know how many Loyalty Currency units would be required to exchange for a $5 Starbucks card. This does not result in issuance of a Gift card. The amount can be provided either in units in the field "amount" or in fiat currency in the field "fiat_amount".

The Gift card exchange feature for the loyalty currency must be enabled in the following section of the Management Dashboard:

*My Currencies > My Own Currency > Settings > Exchange to Gift Cards*


Simulate a gift card exchange

This Endpoint is used to exchange Loyalty currency units for a Gift card. This Endpoint results in issuance of a Gift card. The amount can be provided either in units in the field "loyalty_amount" or in fiat currency in the field "gift_card_amount".

The Gift card issue feature for the loyalty currency must be enabled in the following section of the Management Dashboard:

*My Currencies > My Own Currency > Settings > Exchange to Gift Cards*


Exchange loyalty currency units for gift cards

Direct issue a gift card code

Retrieve an issued gift card code

Validate a custom gift card code

Redeem a custom gift card code

All actions in the system that result in the movement of any Loyalty Currency are represented by a unique Transaction object. E.g. some of the actions are:
- Creation of Loyalty Currency units
- Purchase of partner's Loyalty Currency units
- Issuance or transfer of Loyalty Currency to a member, partner, or other accounts
- Exchange of Loyalty Currency units to another Loyalty Currency
- Redemption of Loyalty Currency units to gift cards or other products

Transaction Endpoints can be used to create a transaction, retrieve information of a transaction, all transactions of a member, or all transactions related to your account. These Endpoints can also be used to cancel or update a transaction.

NOTE: Create a Transaction CANNOT be used to do accruals and redemptions, including Gift Cards and Currency Exchange. Use Accruals and Redemptions Endpoints for such actions; the system will automatically create the underlying required transaction.

## The Transaction object
<SchemaDefinition schemaRef="#/components/schemas/Transaction" showReadOnly={true} showWriteOnly={true} />


Transactions

This Endpoint allows you to retrieve the details of all the transactions of the specified member. To retrieve information about a specific transaction, use 'Retrieve a transaction' Endpoint.

List a member's transactions

This Endpoint allows you to retrieve the details of all the transactions. To retrieve information about a specific transaction, use 'Retrieve a transaction' Endpoint.

List transactions

This Endpoint allows you to create a transaction in the system. This Endpoint should ONLY be used for transaction types of "transfer" such as from a member to another member, from one partner account to another partner account, or transfer between your own accounts. This Endpoint should NOT be used for issuing Currency to members, exchanging loyalty currencies, redeeming Gift Cards, or other redemptions. Relevant Endpoints (Accruals and Redemptions) should be used for the corresponding use cases.


Create a transaction

This Endpoint allows you to retrieve the details of a specific transaction.

Retrieve a transaction.

This Endpoint allows you to update the details of a specific transaction. A transaction can only be updated if its status is pending and the update is requested either by the owner of the origin account of the transaction or the creator of the transaction.

NOTE: Use the "Adjust a Redemption" Endpoint to refund or modify a Redemption transaction, if permitted by the Currency Owner.


Update a transaction

This Endpoint allows you to cancel a specific transaction. A transaction can only be canceled if its status is pending and the cancellation is requested either by the owner of the origin account of the transaction or the creator of the transaction.

NOTE: Use the "Adjust a Redemption" Endpoint to refund or modify a Redemption transaction, if permitted by the Currency Owner.


Cancel a transaction

Partners Endpoints are used to retrieve information about Partners and specific Partnerships with those Partners. These Endpoints provide information such as Company Name, Logos, Loyalty Currency Information, the terms of the partnership(s), actions available, and the required fields for the actions available. This information can be used to drive different UX paths and to automate API calls.


Partners

This Endpoint will be used to either get the list of all the Partners or details about a specific Partner. This Endpoint provides a Partner overview without providing the details of each type of Partnership that you may have with each Partner. The response provides information such as Partner ID, Company Name, Logo, Loyalty Currency Information, and what type of Partnerships are active. The Endpoint has two input parameters, both optional. Provide a value in either one of the fields if you want to retrieve information about a specific Partner. If no value is provided in either parameter, the system will return a list of all the active partners.

List all partners

This Endpoint is used to either get the list of the Exchange In Partners or details about a specific Exchange In Partner. This Endpoint provides the details of the partners who can Exchange IN to my currency. The response provides information such as Partner ID, Company Name, Logo, Loyalty Currency Information, and Partnership details including minimum and maximum transaction size, actions available, fields required, etc.

The Endpoint has two input parameters, both optional. Provide a value in either one of the fields if you want to retrieve information about a specific Partner. If no value is provided in either parameter, the system will return a list of all the active partners.


List exchange in partners

This Endpoint is used to either get the list of the Exchange Out Partners or details about a specific Exchange Out Partner. This Endpoint provides the details of the partners where I can Exchange OUT from my currency to their currency. The response provides information such as Partner ID, Company Name, Logo, Loyalty Currency Information, and Partnership details including minimum and maximum transaction size, actions available, fields required, etc.

The Endpoint has two input parameters, both optional. Provide a value in either one of the fields if you want to retrieve information about a specific Partner. If no value is provided in either parameter, the system will return a list of all the active partners.


List exchange out partners

This Endpoint is used to either get the list of all the Issuing Partners or details about a specific Issuing Partner that is issuing your Loyalty Currency. This Endpoint provides the details of the Issuing Partnership with each Partner. The response provides information such as Partner ID, Company Name, Logo, and Partnership details including minimum and maximum transaction size, actions available, fields required, etc.

The Endpoint has two input parameters, both optional. Provide a value in either one of the fields if you want to retrieve information about a specific Partner. If no value is provided in either parameter, the system will return a list of all the active partners. Generally, Issuing Partners will not have their own Loyalty Currency, hence, send the value in the Partner ID input parameter in that case.


List issuing partners

This Endpoint is used to either get the list of all the Redemption Partners or details about a specific Redemption Partner that is accepting your Loyalty Currency as a mode of payment or redemption for its products or services. This Endpoint provides the details of the Redemption Partnership with each Partner. The response provides information such as Partner ID, Company Name, Logo, and Partnership details including minimum and maximum transaction size, actions available, fields required, etc.

The Endpoint has two input parameters, both optional. Provide a value in either one of the fields if you want to retrieve information about a specific Partner. If no value is provided in either parameter, the system will return a list of all the active partners. Generally, Redemption Partners will not have their own Loyalty Currency, hence, send the value in the Partner ID input parameter in that case.


List redemption partners

This Endpoint is used to either get the list of all the Currency Owner Partners or details about a specific Redemption Currency Owner Partner for redemption i.e. the Currency Owner(s) whose Loyalty Currency you are accepting as payment in exchange for your products or services. This Endpoint provides the details of the Redemption Currency Partnership with each Partner. The response provides information such as Partner ID, Company Name, Logo, Loyalty Currency Information, and Partnership details including minimum and maximum transaction size, actions available, fields required, etc.

The Endpoint has two input parameters, both optional. Provide a value in either one of the fields if you want to retrieve information about a specific Partner. If no value is provided in either parameter, the system will return a list of all the active partners.


List currency owners for redemption partners

This Endpoint will be used to either get the list of all the Currency Owner Partners or details about a specific Currency Owner Partner for issuance i.e. the Currency Owner whose Loyalty Currency you are issuing to its members. This Endpoint provides the details of the Issuance Currency Partnership with each Partner. The response provides information such as Partner ID, Company Name, Logo, Loyalty Currency Information, and Partnership details including minimum and maximum transaction size, actions available, fields required, etc.

The Endpoint has two input parameters, both optional. Provide a value in either one of the fields if you want to retrieve information about a specific Partner. If no value is provided in either parameter, the system will return a list of all the active partners.


List currency owners for issuing partners

Exchange Reports

Retrieve the csv report of the exchange out transactions done by members during a specified time duration. Use the List Transactions endpoint for the report in the standard JSON format.

Retrieve currency exchange report

Custom Gift Cards

This Endpoint is used to retrieve information about gift card codes that have been issued to partner loyalty programs. This only returns the information of the custom gift cards for which you have provided the gift card codes in advance to the Covalent system.

List issued custom gift card codes

This Endpoint is used to retrieve the inventory status of gift card codes of all the custom gift cards for which you have provided the gift card codes in advance to the Covalent system.

List custom gift card inventory

This Endpoint is used to retrieve the inventory status of gift card codes of a specific custom gift card for which you have provided the gift card codes in advance to the Covalent system.

Retrieve a custom gift card inventory

Cohorts

List cohorts

Create a cohort. This feature is only available for Loyalty Currency owners.

Create a cohort

Retrieve a cohort.

Updates the information of an existing cohort.


Update a cohort

Cohort Purchases

List a cohort's purchase loyalty rules

Update a cohort's purchase loyalty rule

Simulates the execution of the enabled cohort loyalty rules matching the purchase from the specified member.

The purchase loyalty rules can be defined at the following section:
  *Loyalty Rules > Purchase Rules*


Executes the enabled cohort loyalty rules matching the purchase from the specified member.

The purchase loyalty rules can be defined at the following section:
  *Loyalty Rules > Purchase Rules*


Execute a purchase

Cohort Activities

List a cohort's activity loyalty rules

Update a cohort's activity loyalty rule

Simulates the execution of the enabled cohort activity loyalty rules matching the received activity identifier.

The purchase loyalty rules can be defined at the following section:
  *Loyalty Rules > Activity Rules*


Simulate an activity rule execution

Executes the enabled cohort activity loyalty rules matching the received activity identifier.

The purchase loyalty rules can be defined at the following section:
  *Loyalty Rules > Activity Rules*


Execute an activity rule

Cohort Accounts

Retrieve the accounts of the specified cohort

List a cohort's accounts

Covalent API Documentation

Covalent API

Production

Sandbox

<h2 class="slate-h2">Introduction</h2><p class="slate-p" placeholder="Type / for widgets">The Covalent API facilitates the design and implementation of a large variety of loyalty program use cases for our clients. Generally, we will implement programs directly. These API docs are intended to give a sense of the API end points that our clients call to build into their warehouse and customer facing environment. Our API allows our Partners to:</p><ul class="slate-ul"><li class="slate-li"><div style="position:relative">Issue, Transfer, Redeem, or Exchange their loyalty currency via API</div></li><li class="slate-li"><div style="position:relative">Pull Transaction History Details </div></li></ul><p class="slate-p" placeholder="Type / for widgets">To benefit from the Covalent platform, you do not need to use all of these features. While there are many Endpoints for specific use cases, most clients end up using only a few Endpoints.
</p><p class="slate-p" placeholder="Type / for widgets"></p><h2 class="slate-h2">Architecture</h2><p class="slate-p" placeholder="Type / for widgets">The Covalent API is organized around REST. Our API has predictable resource-oriented URLs, accepts JSON-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.

Calls to the API have to be properly authenticated using your public andsecret API keys. We will facilitate your access to these keys.

The API is designed for a server to server communication. If you want to communicate with the API from a client it must be through a server environment, to protect the integrity of the requests and the API keys, and not expose them on front-end platforms.</p><h2 class="slate-h2">Authentication</h2><p class="slate-p" placeholder="Type / for widgets">The API authenticates every request based on two elements - Credential and Signature. Every request must include an `Authorization` header with the following two elements.
`Credential=&lt;public-key&gt;, Signature=&lt;calculated-signature&gt;`

Credential
In this parameter, the API requires you to provide the `&lt;public-key&gt;` that is unique to your account. 

## Signature
### How is the Signature calculated?
  The signature is a [HMAC-SHA256](https://en.wikipedia.org/wiki/HMAC) hash in hexadecimal of the request content, using the `private_key` as the key.
  Keep in mind that the string you use to generate the signature and the string you send to the API has to be exactly the same. This includes newlines and spaces. If you compress the JSON body of your request, after generating the signature, the request will be rejected.

### POST/PUT/PATCH HTTP methods
  These types of requests use the string representation of the body to calculate the signature.

  For example, for the request with body: `{&quot;foo&quot;: &quot;bar&quot;}` the signature calculated using `sec_12345` as the private key would be `4d84ba663b9c6179dd98023087da5baa8a4e3eb59ba45284935261350ba70742`

### GET HTTP method
  This type of request uses the query string to calculate the signature. Take into account that the &quot;?&quot; character must not be included while calculating the signature.

  For example, for the request with query string: `?foo=bar` the signature calculated using `sec_12345` as the private key would be `88d64dfcb542c35dc22bae059bd5f5a5d038572a7b391dfc4cd5f3a5530c1760` which is the hash for the string &quot;foo=bar&quot;

  To generate the signature of a GET request without any parameters, simply encode an empty string.
</p><p class="slate-p" placeholder="Type / for widgets">
# Security
The API uses asymmetric cryptography to authenticate requests using the API keys we provide. This provides the following assurances:
  - **Requester identification:** Every request requires your public key to be sent, in conjunction with a signature generated with your secret key.
  - **Protection against man-in-the-middle (MITM) attacks:** The request signature is calculated using the body of the request, which means that any request that has been tampered with during the transport will be rejected by the Covalent platform, since the signature received will not match the request contents.

The API only supports requests over HTTPS.
</p><p class="slate-p" placeholder="Type / for widgets">
# Idempotency
The API supports [idempotent](https://en.wikipedia.org/wiki/Idempotence) requests to safely retry requests without having to worry about doing the same operation more than once.
For example, if there&apos;s a connection error generating a gift card, you can retry the request with the same idempotency key without having to worry about creating multiple gift cards.

To send an idempotent request, include an additional `Idempotency-Key: &lt;key&gt;` header in the request. An Idempotency Key `&lt;key&gt;` is a unique identifier generated by the client with a length between 1 and 255 characters. While this can be any type of unique key, we recommend a UUID to avoid collisions. An Idempotency key expires 8 hours after the initial request.

In a repeated request the response will always have the response body of the original request, along with the same status and `400` errors, if any. The response will also include the header `Idempotency-Repeated: true`. In the rare instances where a request is repeated while the first one has not been completed yet, the API will respond with a `409 - Conflict` status.

The API supports idempotency on POST and PATCH requests. Since GET, PUT and DELETE are idempotent by default, the `Idempotency-Key` header will be ignored.

</p><p class="slate-p" placeholder="Type / for widgets">
# Key fields
Covalent acts as a connectivity bridge between various partners using its standardized APIs and interface, hence, shielding each partner from the complexity, nuances, and customizations of hundreds of loyalty systems and merchant partners. However, the interacting partners need to have a common reference for a transaction in their own system for easy reconciliation as well as for customer support purposes.
In this section, you will find information on some key fields and attributes that are used through our API and on different objects. This information will help you understand how to use these key fields.

## External Reference
The field `external_reference` is used for each transaction request to provide a unique identifier from your system that can be used as a reference during the reconciliation process. This could be a GUID, internal transaction identifier, invoice number, booking number, itinerary number, or any other unique number in your system that can be used to uniquely identify the action. Even though this is not a required field, it is strongly recommended that you provide value in this field.

## Loyalty System Id
The field `loyalty_system_id` is returned by our system on each transaction and it provides the unique identifier in the partner loyalty system. This ID is not generated by Covalent but is provided by the partner loyalty program and hence could be used as a common field for reconciliation between your system and the partner&apos;s system.

## Loyalty System Data
Sometimes, a loyalty program requires you to send some additional data to connect. For example, user_id, application_id, partner_code, etc. You will be able to provide the data in this field for all the transactions with the partner loyalty program. To check if and what additional data is required by the partner loyalty program, refer to the Partners Endpoint.
</p><p class="slate-p" placeholder="Type / for widgets">

# Common Use cases
Our API can be used for numerous Loyalty Commerce use cases. Some of the most common use cases are mentioned below along with the information on which Endpoints to use for each use case. There are auxiliary Endpoints that could be used to enhance your integration and customer experience. For example, you could pull all transaction history out via the API into your Business Intelligence or data staging environments or you could validate the member details before issuing Loyalty Currency Units.

## Accrual/Issue/Top-up
The underlying objective of this use case is to “give Loyalty Currency Units to a member” for one reason or another. The reason could be a purchase of a product, their birthday, completion of a survey, referral, customer service issue, etc. Furthermore, you may want to give the member units of your own Loyalty Currency or one of your Partners’ Loyalty Currency.

You should use Accruals Endpoints for this use case. There are three Endpoints that can be used for issuing your or a Partner’s currency. You can use any one of the Endpoints or a combination of them to issue Loyalty Currency Units to the member.

### Direct Accruals
This Endpoint is to be used when you know the exact number of Loyalty Currency Units to give to a member. In this scenario, you are calculating the number of Loyalty Currency Units in your environment and providing the exact number of units in the endpoint.

### Purchase Rules
This Endpoint is to be used when you would like to give the number of Loyalty Currency Units based on Purchase Rule(s) defined in the Covalent system. For example, giving points worth 1% of the fiat transaction amount. In this case, your application does not need to know how to calculate the number of Loyalty Currency Units or even the cost of the Loyalty Currency Units in any of your Partners&apos; programs.

### Activity Rules
This Endpoint is to be used when you would like to issue the number of Loyalty Currency Units based on pre-defined Activity Rule(s) in the system. For example, you might offer 200 points for posting a product review or referring a friend.

## Currency Exchange
Our API provides tools for quick collaboration among brands to enable their respective members to exchange loyalty units between programs. The exchange could be one-way only, or both directions – in and out – of the programs. Use the Loyalty Currency Exchange Endpoints to implement this use case. There are 2 Endpoints that can be used to enable exchange between partners.

### Simulate an exchange
This Endpoint allows you to simulate how many Loyalty Currency units the member would receive of a Partner’s Loyalty Currency in exchange. This can be used to show the member how many points in one or more programs they could get if completing the exchange.

### Execute an exchange
This Endpoint allows you to comlete the exchange Loyalty Currency units to the Partner’s Loyalty Currency.

**Tip:** You could use the Partners Endpoints to get the list of Exchange Partners and automatically display the fields required for each program to complete the exchange. This will be necessary for loyalty programs that require more member validation fields than just the membership number.

## Redemption/Pay with Points
Our Redemption Endpoints have standardized the redemption process across various types of loyalty programs and underlying loyalty systems. This shields you from needing to understand the underlying complexity to integrate into a new loyalty system or modifying the existing integration for a different set of parameters for a new partner.

You should use Standard Redemption Endpoints for this use case. There are four Endpoints that can be used for allowing a Partner’s Loyalty Currency as a form of payment. You can use any one of the Endpoints or a combination of them depending on your customer journey. Although not necessary, we highly recommend you use the  “Lookup a Member” Endpoint to validate if the member exists and if they have enough balance to complete the payment before submitting the payment transaction.

Strictly speaking, Loyalty Exchange and Exchange for Gift Cards are also redemptions, but we provide explicit Endpoints for those actions due to the very high occurrence of those use cases in the industry. Standard Redemptions refers to any other redemptions where the Partners have allowed the member to redeem (exchange) their Loyalty Currency Units for your Products and Services. The products and services may range from flower delivery to booking a trip, buying an insurance plan, topping up their mobile plan, paying at a restaurant, buying concert tickets, or even applying points toward the purchase of a car.

### Simulate a Redemption
To simulate the redemption action and provide information to the member such as the number of points required to complete the action, cancellation allowed, etc. without actually deducting the points from their balance or completing the transaction.

### Execute a Redemption
Deduct points from the member’s account in exchange for the product or service offered.

### Adjust a Redemption
If allowed by the Partner, you may use this Endpoint to notify of any modification in an already completed Redemption. The system will automatically identify if more points are to be redeemed or points are to be refunded to the member.

### Cancel a Redemption
If allowed by the Partner, you may use this Endpoint to cancel an already completed Redemption to refund the points.
</p><p class="slate-p" placeholder="Type / for widgets"></p><p class="slate-p" placeholder="Type / for widgets"></p>

The Covalent API facilitates the design and implementation of a large variety of loyalty program use cases for our clients. Generally, we will implement programs directly. These API docs are intended to give a sense of the API end points that our clients call to build into their warehouse and customer facing environment. Our API allows our Partners to:

To benefit from the Covalent platform, you do not need to use all of these features. While there are many Endpoints for specific use cases, most clients end up using only a few Endpoints.


The Covalent API is organized around REST. Our API has predictable resource-oriented URLs, accepts JSON-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs.

Calls to the API have to be properly authenticated using your public andsecret API keys. We will facilitate your access to these keys.

The API is designed for a server to server communication. If you want to communicate with the API from a client it must be through a server environment, to protect the integrity of the requests and the API keys, and not expose them on front-end platforms.

The API authenticates every request based on two elements - Credential and Signature. Every request must include an `Authorization` header with the following two elements.
`Credential=&lt;public-key>, Signature=&lt;calculated-signature>`

Credential
In this parameter, the API requires you to provide the `&lt;public-key>` that is unique to your account. 

## Signature
### How is the Signature calculated?
  The signature is a [HMAC-SHA256](https://en.wikipedia.org/wiki/HMAC) hash in hexadecimal of the request content, using the `private_key` as the key.
  Keep in mind that the string you use to generate the signature and the string you send to the API has to be exactly the same. This includes newlines and spaces. If you compress the JSON body of your request, after generating the signature, the request will be rejected.

### POST/PUT/PATCH HTTP methods
  These types of requests use the string representation of the body to calculate the signature.

  For example, for the request with body: `{"foo": "bar"}` the signature calculated using `sec_12345` as the private key would be `4d84ba663b9c6179dd98023087da5baa8a4e3eb59ba45284935261350ba70742`

### GET HTTP method
  This type of request uses the query string to calculate the signature. Take into account that the "?" character must not be included while calculating the signature.

  For example, for the request with query string: `?foo=bar` the signature calculated using `sec_12345` as the private key would be `88d64dfcb542c35dc22bae059bd5f5a5d038572a7b391dfc4cd5f3a5530c1760` which is the hash for the string "foo=bar"

  To generate the signature of a GET request without any parameters, simply encode an empty string.



# Security
The API uses asymmetric cryptography to authenticate requests using the API keys we provide. This provides the following assurances:
  - **Requester identification:** Every request requires your public key to be sent, in conjunction with a signature generated with your secret key.
  - **Protection against man-in-the-middle (MITM) attacks:** The request signature is calculated using the body of the request, which means that any request that has been tampered with during the transport will be rejected by the Covalent platform, since the signature received will not match the request contents.

The API only supports requests over HTTPS.



# Idempotency
The API supports [idempotent](https://en.wikipedia.org/wiki/Idempotence) requests to safely retry requests without having to worry about doing the same operation more than once.
For example, if there's a connection error generating a gift card, you can retry the request with the same idempotency key without having to worry about creating multiple gift cards.

To send an idempotent request, include an additional `Idempotency-Key: &lt;key>` header in the request. An Idempotency Key `&lt;key>` is a unique identifier generated by the client with a length between 1 and 255 characters. While this can be any type of unique key, we recommend a UUID to avoid collisions. An Idempotency key expires 8 hours after the initial request.

In a repeated request the response will always have the response body of the original request, along with the same status and `400` errors, if any. The response will also include the header `Idempotency-Repeated: true`. In the rare instances where a request is repeated while the first one has not been completed yet, the API will respond with a `409 - Conflict` status.

The API supports idempotency on POST and PATCH requests. Since GET, PUT and DELETE are idempotent by default, the `Idempotency-Key` header will be ignored.




# Key fields
Covalent acts as a connectivity bridge between various partners using its standardized APIs and interface, hence, shielding each partner from the complexity, nuances, and customizations of hundreds of loyalty systems and merchant partners. However, the interacting partners need to have a common reference for a transaction in their own system for easy reconciliation as well as for customer support purposes.
In this section, you will find information on some key fields and attributes that are used through our API and on different objects. This information will help you understand how to use these key fields.

## External Reference
The field `external_reference` is used for each transaction request to provide a unique identifier from your system that can be used as a reference during the reconciliation process. This could be a GUID, internal transaction identifier, invoice number, booking number, itinerary number, or any other unique number in your system that can be used to uniquely identify the action. Even though this is not a required field, it is strongly recommended that you provide value in this field.

## Loyalty System Id
The field `loyalty_system_id` is returned by our system on each transaction and it provides the unique identifier in the partner loyalty system. This ID is not generated by Covalent but is provided by the partner loyalty program and hence could be used as a common field for reconciliation between your system and the partner's system.

## Loyalty System Data
Sometimes, a loyalty program requires you to send some additional data to connect. For example, user_id, application_id, partner_code, etc. You will be able to provide the data in this field for all the transactions with the partner loyalty program. To check if and what additional data is required by the partner loyalty program, refer to the Partners Endpoint.




# Common Use cases
Our API can be used for numerous Loyalty Commerce use cases. Some of the most common use cases are mentioned below along with the information on which Endpoints to use for each use case. There are auxiliary Endpoints that could be used to enhance your integration and customer experience. For example, you could pull all transaction history out via the API into your Business Intelligence or data staging environments or you could validate the member details before issuing Loyalty Currency Units.

## Accrual/Issue/Top-up
The underlying objective of this use case is to “give Loyalty Currency Units to a member” for one reason or another. The reason could be a purchase of a product, their birthday, completion of a survey, referral, customer service issue, etc. Furthermore, you may want to give the member units of your own Loyalty Currency or one of your Partners’ Loyalty Currency.

You should use Accruals Endpoints for this use case. There are three Endpoints that can be used for issuing your or a Partner’s currency. You can use any one of the Endpoints or a combination of them to issue Loyalty Currency Units to the member.

### Direct Accruals
This Endpoint is to be used when you know the exact number of Loyalty Currency Units to give to a member. In this scenario, you are calculating the number of Loyalty Currency Units in your environment and providing the exact number of units in the endpoint.

### Purchase Rules
This Endpoint is to be used when you would like to give the number of Loyalty Currency Units based on Purchase Rule(s) defined in the Covalent system. For example, giving points worth 1% of the fiat transaction amount. In this case, your application does not need to know how to calculate the number of Loyalty Currency Units or even the cost of the Loyalty Currency Units in any of your Partners' programs.

### Activity Rules
This Endpoint is to be used when you would like to issue the number of Loyalty Currency Units based on pre-defined Activity Rule(s) in the system. For example, you might offer 200 points for posting a product review or referring a friend.

## Currency Exchange
Our API provides tools for quick collaboration among brands to enable their respective members to exchange loyalty units between programs. The exchange could be one-way only, or both directions – in and out – of the programs. Use the Loyalty Currency Exchange Endpoints to implement this use case. There are 2 Endpoints that can be used to enable exchange between partners.

### Simulate an exchange
This Endpoint allows you to simulate how many Loyalty Currency units the member would receive of a Partner’s Loyalty Currency in exchange. This can be used to show the member how many points in one or more programs they could get if completing the exchange.

### Execute an exchange
This Endpoint allows you to comlete the exchange Loyalty Currency units to the Partner’s Loyalty Currency.

**Tip:** You could use the Partners Endpoints to get the list of Exchange Partners and automatically display the fields required for each program to complete the exchange. This will be necessary for loyalty programs that require more member validation fields than just the membership number.

## Redemption/Pay with Points
Our Redemption Endpoints have standardized the redemption process across various types of loyalty programs and underlying loyalty systems. This shields you from needing to understand the underlying complexity to integrate into a new loyalty system or modifying the existing integration for a different set of parameters for a new partner.

You should use Standard Redemption Endpoints for this use case. There are four Endpoints that can be used for allowing a Partner’s Loyalty Currency as a form of payment. You can use any one of the Endpoints or a combination of them depending on your customer journey. Although not necessary, we highly recommend you use the  “Lookup a Member” Endpoint to validate if the member exists and if they have enough balance to complete the payment before submitting the payment transaction.

Strictly speaking, Loyalty Exchange and Exchange for Gift Cards are also redemptions, but we provide explicit Endpoints for those actions due to the very high occurrence of those use cases in the industry. Standard Redemptions refers to any other redemptions where the Partners have allowed the member to redeem (exchange) their Loyalty Currency Units for your Products and Services. The products and services may range from flower delivery to booking a trip, buying an insurance plan, topping up their mobile plan, paying at a restaurant, buying concert tickets, or even applying points toward the purchase of a car.

### Simulate a Redemption
To simulate the redemption action and provide information to the member such as the number of points required to complete the action, cancellation allowed, etc. without actually deducting the points from their balance or completing the transaction.

### Execute a Redemption
Deduct points from the member’s account in exchange for the product or service offered.

### Adjust a Redemption
If allowed by the Partner, you may use this Endpoint to notify of any modification in an already completed Redemption. The system will automatically identify if more points are to be redeemed or points are to be refunded to the member.

### Cancel a Redemption
If allowed by the Partner, you may use this Endpoint to cancel an already completed Redemption to refund the points.


<p class="slate-p" placeholder="Type / for widgets">Member Endpoints can be used to create a new member, look up information on a member, retrieve a member&apos;s details to your system, or update any member&apos;s details. Only the Currency Owner i.e. the loyalty program to which the member belongs has access to create a member or update a member.

The Partners could look up a member to confirm if the member exists, check the member account balance, or other details of the member record based on permissions granted by the Currency Owner.

Covalent has standardized these Endpoints and orchestrates the calls to various Loyalty programs to validate a member, get member details, etc. if the Covalent platform is not the primary data store for the relevant loyalty program.

## The Member object
The Member Object represents a member record. For the loyalty programs where Covalent is not the primary data store for their members, the system will connect with the loyalty program system to fetch the member information and present it in the following format.
&lt;SchemaDefinition schemaRef=&quot;#/components/schemas/Member&quot; showReadOnly={true} showWriteOnly={true} /&gt;
</p>

Member Endpoints can be used to create a new member, look up information on a member, retrieve a member's details to your system, or update any member's details. Only the Currency Owner i.e. the loyalty program to which the member belongs has access to create a member or update a member.

The Partners could look up a member to confirm if the member exists, check the member account balance, or other details of the member record based on permissions granted by the Currency Owner.

Covalent has standardized these Endpoints and orchestrates the calls to various Loyalty programs to validate a member, get member details, etc. if the Covalent platform is not the primary data store for the relevant loyalty program.

## The Member object
The Member Object represents a member record. For the loyalty programs where Covalent is not the primary data store for their members, the system will connect with the loyalty program system to fetch the member information and present it in the following format.
&lt;SchemaDefinition schemaRef="#/components/schemas/Member" showReadOnly={true} showWriteOnly={true} />


Sections