The SDKs provided help you integrate with the qiibee blockchain on both the server-side and the client-side of your application.

The server SDKs allow you to access the qiibee API to submit transfers and read data (eg. transaction history of an address). The client SDKs allow you to do the same operations in a mobile environment but for a single user wallet.


End-user wallets

Wallets for the qiibee platform are simply Ethereum accounts. There are 2 types of end-user wallets that you can create for your end-users: custodial or non-custodial depending on who has control over it. In either case, losing the wallet's secrets means that funds are lost irreversibly.


A non-custodial wallet is a wallet for which the secrets allowing you to use it (the passphrase and private key) never leave the user's device. Thus, the user alone can approve transfers from his/her own funds. At the same time the user is then fully responsbile for the backing up and security of his/her wallet and funds.

Use the client SDKs to create non-custodial wallets and ensure that the wallet secrets are never sent to your servers.

This is the recommended way of creating and handling end-user wallets when the loyalty program is following the design and security principles of Ethereum.


A custodial wallet means that the private key of the wallet is known by the brand (accessible server-side) which means that the brand can take actions on behalf of the end-user (eg. sending a redeem transfer to the brand). This may result in an easier integration, however the brand must keep in mind that it is now responsible for all transactions performed by the end-user's address and for the wallet backup.

Use the server SDKs to create the custodial wallets and store the private keys for each end-user in a secure manner since access to the private key means access and control of the funds.

This approach is recommended when the loyalty program is striving for a seamless user-experience and optimizes for ease of implementation.


Server SDKs


API authentication is required to enable functionality for high-throughput sending of brand reward transactions.

For this purpose, an API key is provided, which follows the JWT standard. This is to be provided as part of the HTTP header, with the key "Authorization" and the value "Bearer <API key>". The server side SDKs allow for passing in the API key as a parameter when constructing the API client object.


Once you install your SDK, you are able to use 2 types of environments:

  • sandbox -
  • live -

The sandbox environment is to be used for testing your code under conditions that replicate the production environment but using test tokens and to detect software bugs early.

The live environment is to be used to run your production application.

The 2 environments are completely disjoint and use separate API keys, available on request. Loyalty tokens and transactions on the sandbox cannot be migrated automatically to the live environment.

To switch to the live environment, you would have to make sure a loyalty token has been created for production use, and that you provide the correct mode (live or sandbox) as a parameter to the SDK or switch the base API url as shown above, if you are using the API directly.

Supported languages

Currently qiibee provides a Python reference implementation, with more languages in the roadmap. Check out the detailed docs and API reference.


Client SDKs

For integration within your mobile app, qiibee currently provides the following SDKs:

These libraries enable you to create non-custodial wallets for end-users, store them securely, fetch transaction data and balances directly from the API, and construct and send transactions signed by the end-user's wallet.

This way you can easily create wallets that only owned by the end users and give the end-users the ability to do redeem transactions to your brand address.