# 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](/operate/reconciliation/) to identify differences between the records that should agree.