Build a useful operating view
Connect partner balances, recorded activity, yield context and revenue calculations without mixing their meanings.
A good operating view answers what changed, which customers it affects and what the team should do next. Use each API resource for the question it can answer.
| Question | Resource |
|---|---|
| What is the account-level picture? | /partner/summary |
| Which customers are attributed to us? | /partner/users |
| What is a customer's current position? | /partner/user/{id}/positions |
| What activity is recorded for that customer? | /users/{id}/ledger |
| What rates were observed for the asset? | /yield/history/{asset} |
| What is the partner revenue estimate? | /partner/revenue |
| Which requests and delivery attempts need attention? | /usage and /webhooks/deliveries |
Keep observations and calculations distinct
Protocol APY history comes from recorded vault observations. Position values and partner revenue include calculation logic. Transactions and onchain balances establish a different part of the account's state.
Label each number so a product manager or support operator can identify the source and time. Do not turn a revenue projection into a payout label or a protocol APY into a customer's realized return.
Handle fresh and unavailable data
A newly connected partner may have no users or positions. A new deployment may have no rate history. An upstream monitoring failure can make an observed balance unavailable.
These require different interface states. An empty list is not a service outage, and a missing observation is not a confirmed zero balance.
Make the view actionable
Give operators a path from an account summary to the customer, position, ledger and relevant transaction. Keep the request or event identifier available for support. Use reconciliation to identify differences between the records that should agree.