In beginning of integration project Tesseract delivers you 2 set of credentials and both credentials are needed to make both DeFI and Lending products available for end users. In other words you access DeFI products and associated accounts using different credentials than the Lending ones.
Figure 1. illustrates the simple datamodel on Earn Api side. Each user has multiple accounts to store transactions related to a particular product. Caveat is that your data model and code must be able to map to accessing Earn Api using multiple credentials.
Example: Product list
Product list displayed for your end users is union of 2 calls to GET /v1/products.
Example: Creating users
For each end user on your side you create 2 users on Earn Api by calling POST /v1/users with token for both DeFI and Lending. You need to store user id received as response with its mapping to your end user because you need the mapping for other use cases e.g. creating the accounts.
Example: Partner data model
This is very much indicative and details up to partner to design. You can copy paste the dbml code to some online tool for easier viewing of comments associated.
```dbml
Table tesseract_product_types {
id integer [primary key]
tesseract_type varchar [note: '''
lending = Use OAuth2 access token acquired using Lending/Staking secrets delivered
defi = Use OAuth2 access token acquired using DeFi secrets delivered
''']
Note: '''
Table to allow mapping products, users and accounts to Lending/DeFi authentication \
credentials before calling Earn Api.
'''
}
Table tesseract_products {
id varchar [primary key, note: 'id from GET /v1/products']
tesseract_product_type_id integer [ref: > tesseract_product_types.id]
name varchar
rate varchar
Note: '''
Stores unified product list of Tesseract Lending and DeFi products. Contents of this \
table can be presented to end user.
Contents should be populated and updated by calling GET /v1/products a few times \
per day from a scheduled background task.
'''
}
Table partner_users {
id varchar [primary key]
Note: '''
Table that partner should already have.
'''
}
Table tesseract_users {
id varchar [primary key, note: 'id from POST /v1/users response']
partner_user_id varchar [ref: > partner_users.id]
tesseract_product_type_id integer [ref: > tesseract_product_types.id]
Note: '''
Table for storing Tesseract user id's from POST /v1/users response. Partner backend must be \
able to map their user id to Tesseract user id in order to call some other Earn Api \
endpoints e.g. POST /v1/accounts.
'''
}
Table tesseract_user_accounts {
id varchar [primary key, note: 'id from POST /v1/accounts response']
tesseract_user_id varchar [ref: > tesseract_users.id]
tesseract_product_id varchar [ref: > tesseract_products.id]
Note: '''
Table for storing Tesseract user account id's from POST /v1/accounts response. The id is \
required by deposit (POST /v1/accounts/{accountId}/deposit) and withdrawal \
(POST /v1/accounts/{accountId}/withdraw) operations.
'''
}
Table tesseract_user_account_transactions {
id varchar [primary key, note: 'id from POST /v1/accounts/{accountId}/deposit and POST /v1/accounts/{accountId}/withdraw']
tesseract_user_account_id varchar [ref: > tesseract_user_accounts.id]
type varchar [note: 'Deposit / Withdrawal / Interest']
amount varchar
Note: '''
Table to store transactions for purposes of balance calculation by partner backend.
When making Deposit or Withdrawal operation Earn Api responds with the created transaction \
and partner backend can log it into this table at that point. Interest transactions are \
included in reports available via GET /v1/reports endpoint.
'''
}
Table tesseract_wallets {
tesseract_product_type_id integer [ref: > tesseract_product_types.id]
currency varchar
wallet_address varchar
Note: '''
Table for Tesseract wallet addresses
'''
}
Table tesseract_reports_processed {
tesseract_product_type_id integer [ref: > tesseract_product_types.id]
report_id varchar
Note: '''
Table for settlement logic to store which Tesseract report files have already been \
processed.
'''
}
```
Figure 1. Tesseract data model is simple. However partner data model has to be designed with caveat of accessing different type of products with different Earn Api authentication token.