Data Model Mapping

At the start of an integration project, Tesseract delivers two sets of credentials. Both are necessary to make the available yield products accessible to end users. Different credentials are required to access each product type and their associated accounts.

The data structure on the Earn API side is straightforward. Each user maintains multiple accounts for storing transactions linked to a specific product. The key consideration is that your data model and code must support mapping to Earn API access using multiple credential sets.

Example: product list

The product list displayed for your end users is the union of two calls to GET /v1/products — one with each credential set.

Example: creating users

When establishing end users on your platform, you should create two users on Earn API by invoking POST /v1/users with the appropriate credential set for each product line. Store the user IDs from responses along with mappings to your end users — these mappings are essential for subsequent operations like account creation.

Example: partner data model

Design specifics depend on partner requirements. A reference DBML schema is provided as part of integration onboarding and can be imported into online visualization tools to view table relationships and comments.

Typical tables include:

• tesseract_product_types — product taxonomy snapshot.

• tesseract_products — product catalogue snapshot synced from Earn API.

• partner_users — your own user records.

• tesseract_users — the two Tesseract user IDs per partner user (one per credential set).

• tesseract_user_accounts — per-product / per-currency accounts.

• tesseract_user_account_transactions — transaction log for reconciliation.

• tesseract_wallets — settlement wallet addresses.

• tesseract_reports_processed — tracking for idempotent daily report ingestion.