# Integration process
To ensure a quality integration to our clients, we follow an integration process.
Following this structured process helps ensure a seamless and successful integration with our API and ensures our clients avoid common issues.
# Exploration of features using the DEMO environment
DEMO allows clients to complete the evaluation of the API features and how the issued digital vouchers integrate in the user flow.
At the end of this phase, clients have a good understanding of how to use the API, how it can be integrated in their system and gain familiarity with auth and features. Clients should issue and open sample demo vouchers to clarify how digital vouchers can be integrated into their solution.
Note
Please contact UNIQREWARDS API Support to obtain DEMO credentials.
The catalogue of products to issue can be obtained using the endpoint retrieve catalogue of products. The DEMO catalogue includes all types of products we offer: gift cards (super vouchers), fixed, open-value and product-based vouchers.
The list of available features is available in the features summary.
# Integration with the API and user acceptance tests
Clients integration developments should be initiated using the UAT environment.
At this step, dedicated credentials and a dedicated catalogue of products will be provided.
Note
A first selection of products to include in the UAT catalogue is expected to move to this step. This can be discussed with UNIQGIFT Corporate
The UAT catalogue may be identical or a subset of the expected production catalogue. While a final production catalogue isn't required at this step, including a variety of product types in the UAT catalogue ensures comprehensive support.
The following tests form the basis of UAT for an integration with our Client API:
# Issuance of all products in the UAT catalogue
Please ensure specifically that open-value products are supported. This represents the majority of the products we offer.
The main difference for issuing a open-value vouchers is the need to specify its expected face value.
# Obtain voucher status using retrieve vouchers information
Depending on the use-case, this endpoint may or may not be integrated in the issuance flow.
Typically this endpoint can be used to obtain the properties and current status of vouchers so they can be displayed to the end user (unless vouchers have the property is_status_available set to false in which case the current status is unknown).
It also may be used for operations or for support and investigation as it provides status and usage of issued vouchers.
Please refer to the dedicated documentation page on how to request vouchers statuses.
# Implementation of issue recovery using idempotency
Warning
All voucher issuances performed in production will be invoiced.
To avoid discrepancies with our records of voucher issuances, we require all clients to implement issue recovery using the idempotency (ability to handle repeated requests safely) feature of the API.
An idempotent retry is for instance required in case of a network issue between the client and the API.
Please refer to the dedicated documentation section on idempotent recovery.
# Go-live and production
Requirements
Clients are expected to complete UAT including the above mentioned issuance of open-value products and implementation of issue recovery using idempotency before moving to production.
After completion of UAT, the production credentials will be provided.
You may issue vouchers in production as soon as you have the production credentials 🎉
It is recommended to make a few voucher issuance tests in production before your official launch with end-users. Please inform us in advance of when you plan to perform these tests so we can assist to monitor and confirm the issuances from our end.
Once live, you can refer to troubleshooting and support for the available support we offer.