Objective
To allow Seitrace to accurately display yield-generating opportunities (like staking pools, liquidity pools, vaults, lending markets, etc.) offered by your platform on the Sei blockchain. This requires Providers to expose a standardized API endpoint returning data about their available pools/opportunities.Audience
This document is intended for the technical teams of Yield Providers integrating with Seitrace.Integration Overview
Integrating with Seitrace involves two primary components:- A Dynamic API Endpoint: An HTTP GET endpoint that Seitrace will call periodically to retrieve up-to-date information on your platform’s yield pools and opportunities.
- Static Provider Information: A set of descriptive details about your platform provided separately during the onboarding process.
1. Dynamic Pool Data API (Required)
The base URL for all API requests is:https://example-library-api.com
Each Provider must supply Seitrace with a stable HTTP API endpoint URL.
- Method:
GET
- URL Structure: This will be specific to each Provider (e.g.,
https://api.yourdomain.com/seitrace/pools
). Please provide the exact URL to the Seitrace team during onboarding. - Authentication: Currently, no specific authentication headers are required. The endpoint should be publicly accessible or use standard mechanisms communicated during onboarding if necessary.
- Request Headers: Seitrace will typically include standard headers like
Accept: application/json
. - Request Parameters: No specific query parameters are required by Seitrace for this endpoint at this time.
- Success Status Code:
200 OK
- Content-Type:
application/json
1.1. Overall Response Structure (Response
)
The top-level JSON object must contain a single key, data
, which holds an array of IPoolInfo
objects.
1.2. Pool Information (IPoolInfo
)
Each object within the data
array represents a single yield opportunity and must conform to the IPoolInfo
structure.
1.3. Deposit Token Information (IDepositToken
)
Details about the tokens required for depositing into the pool.
1.4. Reward Breakdown (IRewardData
)
Details the components contributing to the total APR.
1.5. Reward Token Information (IRewardToken
)
Details about the token being distributed as rewards for a specific APR component.
- Note on Token Info (
name
_, _symbol
_, _icon_url
_, _decimals
_, _coingecko_id
): While Seitrace may attempt to look up missing token information using the providedaddress
, it is strongly recommended that Providers include this data directly in the API response for accuracy, performance, and correct display on Seitrace. Please providenull
only if the information is genuinely unavailable from your systems.
1.6. Pool Type (PoolType
)
1.7. Example Response
2. Provider Information (Separate Submission)
In addition to this dynamic pool data API, Seitrace requires some static information about your platform (the Provider). This information is typically collected once during onboarding and updated manually as needed. Please be prepared to provide the following details to the Seitrace team:2.1. Provider Information (ProviderInfo
)
2.2. Example Response
Additional Guidelines
- Data Freshness: The data provided via the API should be kept reasonably up-to-date. Aim for updates at least every 5-15 minutes if possible, especially for TVL and APR/APY figures which can change frequently. If data is less dynamic (e.g., delegated staking APRs), less frequent updates (e.g., hourly) may suffice. Please communicate your expected update frequency to Seitrace.
- Accuracy: Ensure the APR, APY, TVL, and fee data accurately reflects the current state of the pool on your platform.
- Completeness: Provide values for all fields where possible. Use
null
only when data is truly unavailable or not applicable. Accuratepool_url
,pool_address
,deposit_tokens.address
,reward_token.address
,total_apr
, andtvl
are particularly important. - Units: Remember to use percentage values for
total_apr
,total_apy
,aprs.apr
,aprs.apy
, andfee
. Use USD fortvl
. - Error Handling: In case of internal errors preventing data retrieval, the endpoint should return an appropriate HTTP error code (e.g.,
500 Internal Server Error
) with a minimal JSON error message if possible, e.g.,{"error": "Failed to retrieve pool data"}
.