REST API

Reporting corrections and timing#

GET /api/v1/cost-basis (portfolio:read) returns startDate and affected transaction rows. PUT requires an app session and workspace:write; its JSON body is { "executionId": "...", "totalBasis": 1234.56, "acquiredOn": null }. Acquisition date is optional, or a real YYYY-MM-DD date on or before the transaction. DELETE takes { "executionId": "..." } and removes the correction. Both mutations are audited and leave imported rows intact. API bearer tokens cannot change basis.

GET /api/v1/research-refresh (research:read) returns pending, failed (awaiting retry), and latest (queue completion timestamp).

Settings now include reportingStartDate (default 2026-01-01), valuationMode (broker or live), and partial calendar preferences (excludePast, holdings, notable, economic). Notable earnings and economic releases default off.

POST /api/v1/schwab claims a background sync and returns status: "running" with runId, or busy with the current run. Poll GET /api/v1/schwab for recorded endpoint progress and final outcome. Balances and positions for all accounts are updated before historical orders and transactions.

Authenticated API responses include Server-Timing: app measures handler elapsed time, db sums database operation durations, and upstream sums instrumented fetch durations. Concurrent operations can overlap, so summed durations may exceed elapsed time. Existing route-specific metrics remain present. No SQL, URLs or credentials are included. Stream durations describe response setup, not the lifetime of the stream.

The REST API serves the same server-side calculations as the web app, the Claude connector and the Chrome extension, so every number matches across surfaces. It lives at /api/v1 on your Investi deployment and is described by an OpenAPI 3.1 document. No endpoint places, changes or cancels a broker order.

The examples on this page use $INVESTI for your deployment's origin (https://investistocks.vercel.app for the hosted Investi, or your own origin if you self-host) and $TOKEN for a personal access token.

export INVESTI=https://investistocks.vercel.app
export TOKEN=inv_pat_your_token_here

Base path and OpenAPI document#

Every endpoint is under /api/v1. The machine-readable description is at /api/v1/openapi.json. It needs no authentication, uses a relative server URL (/api/v1), and is cached for five minutes.

curl -s "$INVESTI/api/v1/openapi.json" | head -c 400

The document lists every operation with its tag, summary and required scope, and includes the full JSON Schema of the canonical company report under components.schemas.CompanyReport. Other response bodies are typed only as object in the document; the shapes on this page come from the route handlers.

Authentication#

Every endpoint except the OpenAPI document requires one of two credentials.

Personal access tokens#

Send a bearer token in the Authorization header:

curl -s "$INVESTI/api/v1/portfolio" -H "Authorization: Bearer $TOKEN"

• Tokens start with inv_pat_ followed by 43 random URL-safe characters.
• Create one in Settings, under the browser extension and API tokens panel of Connections. The token is shown once. Investi stores only its SHA-256 hash, so it cannot show it to you again.
• The Create token button in Settings makes a read-only token with market:read portfolio:read research:read. The list beside it shows each token's name, scopes and when it was last used, with a Revoke link.
• Personal access tokens do not expire. Revoke a token you no longer use.
• OAuth access tokens issued to MCP clients (prefix inv_at_) are also accepted as bearer tokens, with the scopes the user granted on the consent screen. See Claude (MCP).

If a bearer header is present, Investi uses only the token. An invalid, revoked or expired token returns 401; it never falls back to a session cookie.

Scopes#

There is deliberately no scope that can trade.

To get a token with workspace:write or simulate, create it with POST /api/v1/tokens from a signed-in browser tab on your Investi site (token management accepts only session cookies). For example, in the browser console on your Investi origin:

await fetch("/api/v1/tokens", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "Notes script", scopes: ["research:read", "workspace:write"] }),
}).then((r) => r.json());
// { token: "inv_pat_...", id: "<12 hex chars>", note: "Shown once. ..." }

name is 1 to 80 characters and scopes must list at least one valid scope.

Session cookie#

Requests from the web app itself use the investi_session cookie and get all five scopes. For state-changing methods (POST, PUT, PATCH, DELETE) with cookie auth, Investi checks that the request is same-origin: the Origin header's host must equal the request host, or, when there is no Origin header, Sec-Fetch-Site must be same-origin. A cross-origin request is rejected with 403 and code csrf. Bearer-token requests skip this check because browsers never attach them automatically.

Session-only endpoints#

Some actions are refused for bearer tokens even when the token has the listed scope. They return 403 with code session_required and must be done in the app:

• GET /tokens, POST /tokens, DELETE /tokens/{id}
• PUT /policy (strategy rules)
• PUT /settings
• POST /schwab (sync) and DELETE /schwab (disconnect)
• POST /sample and DELETE /sample
• POST /uploads/token (direct-to-Blob upload tokens)
• POST /playbook/apply (it writes a strategy-rules version)

Responses and errors#

Successful responses are JSON with Cache-Control: private, no-store, except the CSV export and the event stream. Many list endpoints wrap rows in data and add a provenance object that names the source and when it was observed.

GET /portfolio, /orders, /transactions, /securities/{ticker}/history, /securities/{ticker}/intel and the company report also carry freshness: one { observedAt, source, through?, stale?, note? } stamp per dataset (quote, bars, fundamentals, filings, catalysts, analyst), and one per source for orders, fills, balances and positions, plus the Schwab connection (freshness.schwab.state: LIVE, DELAYED, STALE, FAILED or REAUTH_REQUIRED, computed from finished sync runs only). The OpenAPI document describes it as the DataFreshness schema. See Freshness on every dataset. These fields were added alongside the existing ones; nothing was renamed.

Errors use one envelope:

{ "error": { "code": "insufficient_scope", "message": "Token lacks scope workspace:write" } }

Some handlers raise other specific codes with the same envelope. The event stream is the exception: it returns a plain-text 401 Unauthorized instead of the JSON envelope.

Pagination#

GET /transactions, GET /orders and GET /orders/sweep are paginated. Transactions return fills newest first and use a cursor:

The response is { data, nextCursor, provenance }. nextCursor is null on the last page. Treat the cursor as opaque.

GET /orders and GET /orders/sweep take limit (1 to 200, default 50) and cursor (or offset), and answer page: { total, offset, limit, returned, nextCursor }. Other list endpoints return everything or a fixed cap (for example, notes return at most 300 rows; limit narrows that).

Open orders#

Probe lots (positions and orders of the strategy rule's probe size or fewer, 1 share by default) stay in GET /portfolio (each position has probe, and the answer has probes: { maxShares, positions, orders }) and in GET /orders (each row has probe, the summary counts probes). GET /orders/sweep leaves them out and reports probesOmitted. See Probe lots.

GET /orders answers the same object as the get_open_orders MCP tool. Without parameters it returns the working orders' summary and the 50 largest by notional, which stays under about 20,000 characters even for several hundred orders.

The summary carries count, tickers, totalNotional by side, bySession, gtcExtCount, earningsWithin10Days, onRedOrFlagged and earningsUnknown. Each row has the remaining shares, limit, last, distancePct (limit against last, negative means below), notional, session, earnings (date, daysTo, confirmed), verdict and gateCeiling (the policy entry-gate price).

curl -s "https://investistocks.vercel.app/api/v1/orders?mode=summary&session=GTC_EXT&earningsWithinDays=10" \
  -H "Authorization: Bearer $INVESTI_TOKEN"

Two filters and two opt-in field sets were added; nothing was renamed and the default answer is unchanged apart from summary.flags (working orders per flag). flag (comma list) keeps orders carrying any of these flags, never set on probe orders: earnings (the name reports within 10 trading days and the order is GTC_EXT), verdict (the verdict differs from the one in force when the order was entered), stale (open more than 60 days), far (last more than 15% from the limit) and duplicate (more than one working order on the same symbol, side and price, across accounts; a ladder at different prices is not a duplicate). include=flags adds each row's flags ({ id, label }), ageDays, verdictAtEntry and verdictDate (filtering by flag adds them too); include=research adds research: { account, sector, exDividend, low52, pctAboveLow, analystTarget, upsideToTarget } (fractions, null where the source has nothing). Both are in the Open orders screen.

Holdings#

GET /holdings answers { asOf, rows, summary, pending, definitions }, the same builder as the Holdings screen and the get_holdings MCP tool. Each row: ticker, account, shares, avgCost (Schwab's basis when reported; basisSource says which), last, marketValue, unrealized, unrealizedPct, firstBuyDays, oldestLotDays, ageBucket, lotsCount, lots (date, shares, cost, ageDays, account), verdict, verdictDate, verdictLines, nextEarnings, daysToEarnings, exDividend, lastBuyDate, lastSellDate, low52, high52, pctAboveLow, analystAvg, analystLow, analystHigh, upsideToAvg, analystCount, sellOrder and buyOrder (price, distance, count), sector, bucket and buckets, dividends, breakeven and probe. Percentages are fractions. summary has totalMarketValue, totalUnrealized, underwaterCount, underwaterAged (days, value, share), losers (five largest losses) and probes. pending lists symbols whose earnings, dividend or analyst data had not answered yet; their fields are null.

curl -s "https://investistocks.vercel.app/api/v1/holdings" -H "Authorization: Bearer $INVESTI_TOKEN" | jq '.rows[0] | {ticker, unrealizedPct, oldestLotDays, verdict, bucket}'

Order risk sweep#

GET /orders/sweep gives one suggested action per working order, most urgent first, as the order_risk_sweep MCP tool does. The rules, strongest first: cancel for a buy on a RED or FLAGGED name; switch to plain GTC when the name reports within earningsSoonDays (default: your policy's earnings call-out, 7 days; confirmed or estimated dates) and the order is GTC_EXT; review the gate when a buy limit is more than gateTolerancePct (default 1) above the entry-gate ceiling; otherwise OK. OK rows are left out unless includeOk=true. The suggestions are research text: Investi never places, changes or cancels an order, and the response says so in its first field, notice.

Digest and webhooks#

GET /digest (needs research:read and portfolio:read) returns the weekly digest: pnl (week and month realized on average cost, today, lifetime realized, unrealized, dividends, fees, margin interest and net), orders (the open-orders summary), orderRiskSweep, the full weeklyReview, connection (the Schwab state from finished sync runs) and broker (how old the share counts are and whether positions are verified, unverified or unreconciled). Treat the figures as unverified unless broker.reconciliation is verified. The get_digest MCP tool returns the same document.

Investi has no email delivery, so the digest is pushed to webhooks instead. Register an HTTPS URL in Settings, Digest or with POST /webhooks ({ "url": "https://..." }); the response carries the signing secret once. Every Sunday at 22:00 UTC Investi POSTs the digest to each active webhook as { id, event: "digest.weekly", createdAt, data }. POST /webhooks/{id}/test sends it at once as digest.test.

Each delivery has X-Investi-Event, X-Investi-Delivery and X-Investi-Signature: t=<unix seconds>,v1=<hex>, where v1 is HMAC-SHA256 of <t>.<raw body> keyed with the secret. Verify it over the raw body and reject timestamps older than five minutes:

import { createHmac, timingSafeEqual } from "node:crypto";
function verify(secret, rawBody, header) {
  const [, t, v1] = /^t=(\d+),v1=([0-9a-f]{64})$/.exec(header) ?? [];
  if (!t || Math.abs(Date.now() / 1000 - Number(t)) > 300) return false;
  const expected = createHmac("sha256", secret).update(`${t}.${rawBody}`).digest();
  return timingSafeEqual(expected, Buffer.from(v1, "hex"));
}

Registering, listing and testing webhooks needs workspace:write, portfolio:read and research:read, because the digest carries portfolio and research data. Investi records which credential registered each webhook: if a personal token or connected app registered it, revoking that token or app pauses the webhook, and every delivery re-checks the credential first.

URLs must be https, without credentials, and resolve only to public global-unicast addresses (IPv6 forms that embed an IPv4 address, such as 6to4 and Teredo, are judged by that address or refused); redirects are not followed. Each delivery has a hard 10-second total limit, so a receiver should answer 2xx promptly. Deliveries that do not fit in the Sunday run's time budget are skipped, not counted as failures, and go out the next week. After five failed weekly deliveries in a row the webhook is paused; a successful test turns it back on.

CORS and rate limits#

/api/v1 endpoints send no CORS headers and have no OPTIONS handlers, so a page on another origin cannot call them from a browser. Call the API from a server, a script, or the Investi origin itself. The OpenAPI document is the one exception: it sends Access-Control-Allow-Origin: *.

Apart from the two AI budgets above, the API has no rate limiting of its own. Login is the only other rate-limited endpoint; see Security and privacy.

Examples#

Manual check answers#

curl -s -X PUT "$INVESTI/api/v1/securities/DOX/checks" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"checkId":"manual.revealed","answer":"PASS","note":"Guidance cut covers the drop","expiresAt":"2027-02-02"}'

GET lists your answers for the ticker with active (still feeding the verdict) and DELETE ?checkId=manual.revealed removes one. checkId is manual.kodak, manual.legal or manual.revealed; answer is PASS, FAIL or UNKNOWN; expiresAt defaults to 90 days and may not be in the past or more than two years out. Rule outcomes in the report can carry an optional evidence list (date, source, title, snippet, url), and the cap severity was added in policy v3; both are additive to report.v2.

Company report#

curl -s "$INVESTI/api/v1/securities/SPXC/report" \
  -H "Authorization: Bearer $TOKEN"

Needs research:read. Returns the canonical company report, the same object the MCP tools use. Its top-level fields include schemaVersion, reportId, generatedAt, identity, quote, tradingHistory, businessQuality, priceSetup, catalysts, analystViews, strategyVerdict, buyZone, framework, bearBull, changeLog, provenance and disclaimer. The exact schema is in the OpenAPI document. An unrecognized symbol returns 404 not_found.

catalysts.items in report.v2 holds the same catalyst objects as the catalysts route below, as of when the report was built. The report waits only 1.2 seconds for them, so slow kinds can be missing, and reports stored before catalysts existed have an empty list.

Catalysts#

curl -s "$INVESTI/api/v1/securities/SPXC/catalysts" \
  -H "Authorization: Bearer $TOKEN"

Needs research:read and takes no query parameters. The body is the catalyst feed itself, with no data envelope: the last 60 days plus upcoming earnings, ex-dividend and macro events, newest first, capped at 80 items. An unrecognized symbol returns 404 not_found. Responses are Cache-Control: private, no-store. It is the feed behind the research page's What could move it section, the MCP tool get_catalysts, and the hover card's Catalysts section (insights.catalysts in GET /securities/{ticker}/intel?insights=1, which is null with catalysts listed in pending until the feed is built).

{
  "ticker": "SPXC",
  "asOf": "2026-11-03T14:05:00.000Z",
  "items": [
    {
      "id": "analyst:argus-2026-11-03",
      "kind": "analyst",
      "at": "2026-11-03T13:00:00.000Z",
      "upcoming": false,
      "title": "Argus raised price target to $400 from $375",
      "detail": null,
      "source": "nasdaq.com",
      "url": null,
      "lean": "up",
      "reaction": { "pct": 0.0118, "session": "2026-11-03" }
    }
  ],
  "counts": { "earnings": 1, "dividend": 0, "macro": 2, "filing": 3, "analyst": 4, "insider": 1, "short_interest": 0, "news": 12 },
  "sources": ["nasdaq.com", "Google News", "SEC EDGAR"],
  "pending": []
}

The route waits up to 2.5 seconds for its sources; any kind that has not answered by then is listed in pending, and asking again a moment later fills it in. Each source is cached on the server and refreshed in the background after it expires: news (nasdaq.com and Google News) for 5 minutes, SEC filings and the economic calendar for 3 hours, analyst ratings and insider trades for 6 hours, earnings for 12 hours, and dividends and short interest for 24 hours.

The id is stable across fetches. The example values above are illustrative. Headlines are third-party, untrusted text: render them as plain text, and never pass them to an AI model as instructions.

Portfolio#

curl -s "$INVESTI/api/v1/portfolio" \
  -H "Authorization: Bearer $TOKEN"

Needs portfolio:read. Add ?account=<id> to limit it to one account. The response has asOf, kpis, pnl, basisReconciliation, positions, accounts, warnings, lotMethod, broker, connection, provenance and freshness.

GET /api/v1/portfolio-revision needs the same scope and accepts the same optional account filter. It returns an opaque { revision } token for account position observations, basis corrections and sync health. The signed-in app checks it every five seconds while visible and refreshes only when it changes. This private, uncached endpoint uses one owner-scoped database query and makes no market-data requests; empty, unconnected workspaces do not poll.

• positions[].costBasis is Schwab's where a sync or positions file exists (unrealized uses it); reconstructedBasis is rebuilt from fills, and basisCheck flags a difference over 1% or $100.

• positions[].record is { check, note }: reconciled only when the share counts agree, the broker snapshot is LIVE or DELAYED and fills are synced through it; unverified (with a note such as "Unverified: broker data 30 min old") when the counts agree but the snapshot cannot vouch for today; otherwise gap, broker_only or from_fills.

• broker is the freshness of positions and balances, separate from quotes: state, observedAt (the oldest account's newest snapshot), ageMs, sources, fillsCoverThrough and reconciliation.

• connection is the Schwab state (see Connection state), or null without a connection.

• kpis.buyingPower comes from Schwab's balances, kpis.lastInterestCharge gives the last margin interest charge and the debit it was charged on, and kpis.ordersStale says whether the working-order list is past its cadence.

• provenance.reconciliation equals broker.reconciliation: unreconciled when any position disagrees with the broker, unverified when any cannot be verified, and verified otherwise.

• pnl is the canonical P/L breakdown, the same object the app and the MCP tools get_positions and evaluate_strategy_health return: realized, unrealized, dividends, marginInterest, interestEarned, accountFees, tradingFees (already inside realized and basis), net, and what is excluded: legacy (sales of shares bought before your history: proceeds, shares, sells, tickers, firstDate, lastDate), beforeCoverage (cash dated before your first fill), otherCash (unclassified cash) and unpriced (positions with no quote). See Canonical numbers.

• Each position carries brokerBasis, reconstructedBasis (rebuilt from your fills), basisDiff and basisCheck: match, differs (more than 1% or $100 apart), broker_only (no buys on record), reconstructed_only or unknown.

• basisReconciliation totals the broker snapshot: observedAt, sources, brokerBasis, brokerMarketValue, brokerUnrealized (at the snapshot time), comparedBrokerBasis and comparedReconstructedBasis over the positions that have both, flagged, brokerOnly and unrealizedAtQuotes.

Quotes#

curl -s "$INVESTI/api/v1/quotes?symbols=SPXC,AAPL,BRK.B" \
  -H "Authorization: Bearer $TOKEN"

Needs market:read. Up to 400 symbols per call. The response is { data, unknown, provenance }: data holds one quote per recognized symbol with a freshness label, unknown lists symbols that did not resolve, and provenance.delayedBy is 900 seconds. Quotes are delayed; see Data sources.

For a live feed, GET /stream?symbols=... is a server-sent events stream of feed, quote and heartbeat events (up to 200 symbols). With a connected Schwab account it pushes real-time Schwab Streamer ticks, at most one per symbol every 500 ms; otherwise it polls delayed Nasdaq every 5 seconds. A feed event names the source whenever it changes. It sends only changed snapshots and ends after about 4.5 minutes, so reconnect when it closes; sequence numbers keep rising across reconnects.

Transactions, page by page#

# First page
curl -s "$INVESTI/api/v1/transactions?limit=200&ticker=SPXC" \
  -H "Authorization: Bearer $TOKEN" > page1.json

# Next page: pass nextCursor back, URL-encoded
CURSOR=$(jq -r '.nextCursor' page1.json)
curl -s -G "$INVESTI/api/v1/transactions" \
  --data-urlencode "limit=200" \
  --data-urlencode "ticker=SPXC" \
  --data-urlencode "cursor=$CURSOR" \
  -H "Authorization: Bearer $TOKEN"

Needs portfolio:read. Each row has id, account_id, instrument_id, ticker, side, quantity, price, fees, trade_date, source, basis_source and import_batch_id. Stop when nextCursor is null.

Create a note#

curl -s -X POST "$INVESTI/api/v1/notes" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ticker":"SPXC","kind":"thesis","body":"Adding only inside the buy zone. Recheck after the next 10-Q."}'

Needs workspace:write, so the default read-only token from Settings is not enough (see Scopes). The body takes body (1 to 20,000 characters), an optional ticker, kind (note, decision or thesis, default note) and an optional evaluationId. The response is { "id": "note_..." }. An unknown ticker returns 404 not_found. Note creation is recorded in the audit log.

Ask about a screen#

curl -s "$INVESTI/api/v1/ai/chat" -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"path": "/research/SPXC", "message": "Where is my exit target?"}'
# { "threadId": "thr_...", "assistant": { "content": "...", "model": "..." }, "changes": [], "proposals": [], ... }

With "stream": true the response is application/x-ndjson: {"type":"delta","text":"..."} lines as the model writes, then one {"type":"done", ...} with the same fields, or {"type":"error","code":"...","message":"..."}. See AI page analysis and Uploads, playbook and memory.

Endpoint reference#

Paths are relative to /api/v1. "Session" means the endpoint accepts only the session cookie.

Market#

Research#

Portfolio#

Screener#

Candidates#

GET /api/v1/candidates lists new candidate entrants, newest first. How each source works is in Candidate sources.

The response has entrants, total, counts per source (all, near_low, big_drop, strict, upload), unfiltered (entrants before the verdict and since-days filters), sourceStatus (per source: lastRunAt, state of ok, never_run or degraded, and a note such as "Change feed failed at 2:15 PM ET (too few rows); one-day change from the last two stored daily closes"), rules (your near-low distance, drop threshold, drop sessions and cap floor), newDays, lastVisit, page and nextPage (null on the last page). Page through with nextPage to read the whole list. Each entrant carries sources (each with source, firstSeenAt, lastSeenAt and meta), firstSeenAt, price, changePct, pctAboveLow, verdict (null when not yet evaluated), owned, isNew, dismissed, reentered, reason, why (a short reason computed from its sources, such as "-18.2% in 5d", "new 52W low", "Strict 1: 11/11" or "uploaded Nov 4"), strict (the eleven checks, each pass, fail or unknown, with value and detail) and drop (the big-drop gate's checks, with changePct, sessions and changeSource of feed or bars).

Sold on a day#

GET /api/v1/sold?date=YYYY-MM-DD (portfolio:read) answers what was sold on a New York date, today by default and any past day. It is built only from fills that came from Schwab transactions (API sync) or imported Schwab and broker CSVs, never from the order list or a position snapshot. A sale imported by CSV and later synced from Schwab is one row: the sync skips a day an import already covers.

Each row (one per symbol and account) has shares, avgSellPrice, proceeds (shares times price less the sells' fees), fees, costBasis with basisSource (schwab_reported: Schwab's average cost a share from the last position snapshot before the sale, times the shares; lot_matched: the lots Investi matched from your fills; unknown) and basisNote, realized and realizedPct, heldDays (share-weighted over the lots closed) and heldDaysRange, eodClose (the 4:00 PM close from daily bars; before the close on the same day the live price, with live: true and closeSource: "live_quote"), eodVsSellPct (positive when the sale was above the close), leftOnTable ((close - average sell) x shares when positive, else 0), sharesStillHeld with heldSource (the freshest Schwab position, 0 when fully sold; the ledger when the account has no position after the sale), rebuy (a working buy on the symbol with its limit, current price and distancePct, or null) and fills (each with time, shares, price, fees, source). The answer also has totals (rows, shares, proceeds, costBasis over rows with a basis, realized, realizedPct, leftOnTable, fullySold), beforeClose (today, before the 4:00 PM close or 1:00 PM on early-close days), session (trading: false on weekends and NYSE holidays, closed: weekend or holiday, and previous and next: the adjacent trading days, next null when it would be after today), probesExcluded (sales of the probe size or fewer, see Probe lots) and definitions. A future date or a malformed one answers 400 bad_date.

curl -H "Authorization: Bearer $INVESTI_TOKEN" "https://your-investi/api/v1/sold?date=2026-11-04"

curl -H "Authorization: Bearer $INVESTI_TOKEN" "https://your-investi/api/v1/candidates?source=strict&limit=20"
curl -X POST -H "Authorization: Bearer $INVESTI_TOKEN" "https://your-investi/api/v1/candidates/ADBE/dismiss"

POST /api/v1/candidates/{ticker}/dismiss returns { ticker, refPrice }, where refPrice is the lower of the last price and the 52-week low; the name comes back, marked new, if it trades below it. It answers 404 for a ticker that is not among your candidates.

POST /api/v1/screens/import takes the CSV as a multipart file field, or as a text/csv request body with ?fileName=. The export type is detected from the header (Finviz: No., Ticker, Company; Schwab: Symbol; anything else with a Ticker column is other). It returns { id, source, rowCount, skipped, tickers }, 400 unrecognized_csv when no Symbol or Ticker column or no ticker rows are found, and 413 over 5 MB.

Risk#

Tax and options#

Workspace#

Uploads, playbook, memory and chat#

Access#

Note: Writes under workspace:write change only data inside Investi, such as notes, alerts, watchlists and recorded orders. Recording an order with POST /orders does not send it to Schwab or any other broker.

Related#

• Claude (MCP) for the OAuth-based connector with the same data
• Canonical numbers for why every surface agrees
• Ledger for how round trips and realized P/L are computed
• Security and privacy for how tokens are stored