How to Build a Prediction Market Portfolio Tracker With an API (2026)

A prediction market portfolio tracker sounds simple until a trader has positions on more than one venue.

One account may hold election markets on Polymarket, sports positions on another prediction market, cash sitting idle somewhere else and multiple open orders waiting to fill. Each venue can represent balances, positions, market IDs and fills differently.

If you are building a trading dashboard, fund monitor, agent or analytics product, the real problem is not drawing the portfolio chart.

It is getting all of those positions into one reliable schema.

Predictefy's API gives developers a unified account and portfolio layer for supported prediction markets. Instead of building a separate portfolio adapter for every venue, you can query standardized balances, positions, open orders, fills and cross-venue portfolio values through one infrastructure layer.

What a Prediction Market Portfolio Tracker Actually Needs

A basic portfolio page normally needs six pieces of information:

• cash and collateral balances
• open prediction market positions
• current market value
• entry price and unrealized P&L
• open orders
• trade or fill history

For a cross-venue portfolio tracker, every one of those fields needs a venue attached to it.

That gives you a structure like this:

Why Build the Portfolio Tracker With an API?

You could ask users to manually enter every trade.

That works until they trade again.

You could connect directly to each prediction market and maintain separate account logic for every venue.

That works until your application supports five, ten or more prediction markets.

The API approach is cleaner because the UI becomes separate from the exchange infrastructure.

The front end can then concentrate on answering the questions traders actually care about:

How much is my portfolio worth? Where is my capital? What am I exposed to? Which positions are winning? Which orders are still working?

The Basic Portfolio Tracker Architecture

The portfolio tracker should not scrape prediction market websites or derive balances from what happens to be visible in a browser.

Use account and market APIs as the underlying source and treat each returned field according to its stated availability.

Step 1: Get a Predictefy API Key

Predictefy's API uses Bearer authentication.

Store the key server-side:

PREDICTEFY_API_KEY=pk_live_your_key_here

Then send it in the Authorization header:

Authorization: Bearer pk_live_your_key_here

Do not put a private API credential directly into browser JavaScript.

Step 2: Load the Cross-Venue Portfolio

For a supported public address, the most direct portfolio request is:

GET /v1/portfolio

The required parameter is address.

For example:

curl --request GET \ --url 'https://data.predictefy.com/v1/portfolio?address=YOUR_ADDRESS' \ --header 'Authorization: Bearer pk_live_YOUR_KEY'

In JavaScript:

const address = 'YOUR_ADDRESS'; const response = await fetch( `https://data.predictefy.com/v1/portfolio?address=${encodeURIComponent(address)}`, { headers: { Authorization: `Bearer ${process.env.PREDICTEFY_API_KEY}` } } ); const portfolio = await response.json();

You can also restrict the request to a comma-separated subset of portfolio-capable venues with the optional venues parameter.

GET /v1/portfolio?address=YOUR_ADDRESS&venues=venue_a,venue_b

This is useful if your product only wants to display a selected set of prediction markets.

What the Portfolio Endpoint Gives You

The response is organized by venue and can contain both balances and positions.

For balances, useful normalized fields include:

• venue
• accountId
• currency
• kind
• total
• available
• locked
• asOf

The balance kind can distinguish concepts such as cash, collateral, available-to-trade capital, positions value, perpetual margin, locked capital and other balances.

For prediction market positions, the normalized object can include:

• venue
• accountId
• positionId
• marketId
• canonicalMarketId
• outcomeId
• side
• size
• avgEntryPrice
• markPrice
• unrealizedPnl
• realizedPnl
• status

That is enough to build the core of a prediction market portfolio dashboard without inventing your own position schema for every venue.

Step 3: Display Total Portfolio Value

The portfolio response includes aggregate marking information, including a total marked value in USD where real marks can be resolved.

A simple dashboard card might therefore use:

const totalValue = portfolio.data?.totals?.markValueUsd ?? null;

If the total is null, do not automatically replace it with zero.

Zero means the portfolio is worth zero.

null can mean Predictefy could not produce a valid marked total from the available data.

That distinction is important in any financial dashboard.

How Predictefy Marks Prediction Market Positions

A portfolio tracker needs a current price to turn a position size into a current value.

Predictefy resolves position marks against its normalized market catalog. Where a position can be resolved, the response can include a mark containing:

• USD value
• current price
• mark source
• timestamp

When a position cannot be valued, the API can return mark=null along with a markReason.

Documented reasons include:

A good portfolio interface should show an unavailable value as unavailable, not silently display "$0.00".

Step 4: Break the Portfolio Down by Venue

A single total number hides one of the most important parts of a prediction market portfolio: venue exposure.

Your dashboard should also show how much of the marked portfolio sits on each prediction market.

The portfolio response includes a byVenue breakdown in its totals, which gives you a clean base for cards or a chart.

For example:

The percentages above are just an example UI. Your application should calculate them from the real marked values returned by the API.

A simple calculation is:

const venueShare = venueValue / totalPortfolioValue;

This is useful for both ordinary traders and automated systems because it exposes concentration risk immediately.

Step 5: Load Positions Directly

If you only need positions for a specific venue account, you do not need to request the entire portfolio.

Use:

GET /v1/accounts/{venue}/{accountId}/positions

For example:

const url = `https://data.predictefy.com/v1/accounts/${venue}/${accountId}/positions`; const response = await fetch(url, { headers: { Authorization: `Bearer ${process.env.PREDICTEFY_API_KEY}` } }); const positions = await response.json();

This is useful for a venue page where you want to show only positions held on that prediction market.

Build the Position Table

The core portfolio table should be boring and useful.

For a trader, this table is more useful than a portfolio chart by itself because it explains where the total value actually comes from.

Step 6: Load Balances Separately

Prediction market exposure is only part of the account.

A trader may also have cash or collateral sitting idle.

Use:

GET /v1/accounts/{venue}/{accountId}/balances

This allows you to show metrics such as:

• total balance
• available capital
• locked capital
• collateral
• position value

One useful dashboard distinction is:

Do not collapse all four into one "Balance" card. They answer different questions.

Step 7: Track Open Orders

A portfolio tracker that ignores open orders gives an incomplete picture.

A trader might appear to have $5,000 available while $3,000 of that capital is tied to working orders.

Predictefy exposes:

GET /v1/accounts/{venue}/{accountId}/open-orders

You can use the response to build a separate panel showing:

• venue
• market
• side
• price
• remaining quantity
• order status

Keeping open orders separate from positions also avoids a common UI mistake: treating an order that has not filled as if it were already exposure.

Step 8: Track Fills and Cost Basis

Predictefy also exposes account fills through:

GET /v1/accounts/{venue}/{accountId}/fills

Fills are useful for much more than a trade-history screen.

They can help your application reconstruct how a position was accumulated and calculate average entry information where the underlying venue data supports it.

There is an important limitation to respect: where Predictefy derives unrealized P&L from a bounded fills window, the API labels that basis as fills_window and complete=false.

That means the system is explicitly telling you that the available fill history is not guaranteed to represent the trader's full historical cost basis.

Your interface should preserve that honesty.

Do Not Manufacture Realized P&L

One of the easiest ways to build a misleading prediction market portfolio tracker is to infer more than the data supports.

If complete historical fills are unavailable, you cannot safely reconstruct every realized trade.

Predictefy's portfolio contract explicitly avoids manufacturing realized P&L where that information is not supported.

Your application should do the same.

Use three states:

Step 9: Handle Partial Venue Availability

Cross-venue APIs eventually hit an uncomfortable reality: one venue can be working while another is unavailable.

A weak portfolio API fails the entire request.

A better one tells you what worked and what did not.

Predictefy's portfolio response exposes availability independently for balances and positions by venue.

Possible states include:

• available
• owner_auth_required
• not_supported
• temporarily_unavailable

Your dashboard should preserve those states.

For example:

Do not display "$0" for Venue B's positions. That falsely tells the user they have no position there.

Step 10: Use the Account Capabilities Endpoint

Not every venue exposes the same account data.

Before designing around an account feature, check what that venue supports:

GET /v1/accounts/{venue}/capabilities

This allows your application to make the UI capability-aware instead of assuming every venue provides every field.

For example, the front end can hide a fills tab when the relevant venue does not expose a supported fills lane rather than showing a permanently empty component.

What the Finished Dashboard Should Show

A useful prediction market portfolio tracker does not need twenty charts.

Start with five sections.

Useful Portfolio Metrics to Calculate Yourself

Predictefy gives you the normalized account and market data. Your application can build additional analytics on top.

Venue Concentration

venueConcentration = venueMarkedValue / totalMarkedValue;

Position Concentration

positionConcentration = positionValue / totalMarkedValue;

Capital Deployment

capitalDeployment = positionsValue / (positionsValue + availableCapital);

Unrealized Return

unrealizedReturn = unrealizedPnl / costBasis;

Only calculate a metric when the underlying values are actually available.

Missing data is not zero data.

How Often Should a Prediction Market Portfolio Tracker Refresh?

A portfolio tracker usually does not need to refresh as aggressively as an arbitrage scanner.

The appropriate cadence depends on the product.

Do not let an AI agent make a new trade based on a portfolio snapshot that may no longer reflect its latest fills.

Using the Portfolio API With an AI Trading Agent

The same portfolio API becomes especially useful for AI agents.

Without portfolio context, an agent can identify a good trade while having no idea that the account already has too much exposure to that event or venue.

Before proposing an order, the agent can retrieve the portfolio and answer questions such as:

• How much capital is available?
• What positions are already open?
• How much exposure already exists on this venue?
• Is there already an order working in the same market?
• Would the new position violate a concentration limit?

The architecture becomes:

A Simple Portfolio Tracker Backend

A minimal backend route can be very small:

export async function getPredictionMarketPortfolio(address) { const response = await fetch( `https://data.predictefy.com/v1/portfolio?address=${encodeURIComponent(address)}`, { headers: { Authorization: `Bearer ${process.env.PREDICTEFY_API_KEY}` } } ); if (!response.ok) { throw new Error(`Portfolio request failed: ${response.status}`); } return response.json(); }

Then your application can transform it:

const portfolio = await getPredictionMarketPortfolio(address); const totalValue = portfolio.data?.totals?.markValueUsd ?? null; const venueValues = portfolio.data?.totals?.byVenue ?? {}; const venues = portfolio.data?.venues ?? {};

From there, your UI can build venue cards, position tables and portfolio allocation views without directly knowing how each underlying prediction market represents its account data.

Five Mistakes to Avoid

1. Treating unavailable data as zero. A failed venue adapter does not mean the user has no assets there.

2. Mixing open orders with filled positions. An order is potential exposure. A position is existing exposure.

3. Using stale market prices. A portfolio value is only as current as the marks behind it.

4. Inventing realized P&L from incomplete history. If the cost basis is incomplete, label it accordingly.

5. Showing one total without venue breakdown. A trader with $10,000 split evenly across venues has a different risk profile from a trader with $9,500 concentrated on one platform.

Why Predictefy Is Useful for Portfolio Products

The key benefit is not that Predictefy can draw a portfolio chart for you.

The benefit is that the account data and market data exist inside the same normalized prediction market infrastructure.

A position references a market. That market can be resolved against the same wider catalog used for market discovery, pricing, matched markets and cross-venue analysis.

That means a portfolio product can evolve beyond "show my positions" into questions like:

• Is this position priced differently on another venue?
• Can this exposure be hedged elsewhere?
• Which venue represents most of my portfolio risk?
• Which markets have moved most since entry?
• Where is capital sitting unused?
• Which open orders could materially change my portfolio?

That is where a unified prediction market API becomes more useful than a collection of isolated exchange connectors.

Frequently Asked Questions

Conclusion

A prediction market portfolio tracker is fundamentally a data-normalization problem.

The dashboard itself is the easy part.

The difficult part is combining balances, positions, orders, fills and current market prices from fragmented prediction markets without lying to the user when a field or venue is unavailable.

Predictefy's Accounts & Portfolio API gives developers a normalized layer for that problem.

Use /v1/portfolio for the cross-venue view. Use the account routes when you need more granular balances, positions, open orders or fills. Preserve availability states, respect incomplete P&L data and use normalized marks rather than treating missing values as zero.

Once that foundation exists, the portfolio tracker can become much more than a balance page.

It can become the risk layer for a trading terminal, the account context for an AI agent, or the portfolio intelligence layer for an institutional prediction market product.