/api/tracker/* routes. It calls the same shared tracker functions (lib/tracker/*: entity creation and updates, alert-policy compilation, profile enrichment), reads and writes the same Supabase tables, and triggers the same Python tracker backend.
As a result:
- A company created through the API is indistinguishable from one created in the UI: it is enriched, scheduled, scraped, classified and alerted on the same way, and it appears in the UI.
- Lead decisions are shared. Accepting, rejecting or tracking a lead through the API shows as decided in the UI, and decisions made in the UI are visible through the API.
- The API adds only what an external client needs on top: machine credentials, input validation, stable JSON shapes, idempotent creation, cursor pagination, fuzzy entity and sector lookup, compact views and rate limits.
Because a few UI steps are re-implemented rather than shared (forcing the email action onto compiled alert rules, the lead “Track” mapping, the lead decision key), changes to those UI behaviours must be mirrored in
lib/partner-api/.Resources
Tracker
Same entities as the Tracker UI in
rg-v2.Signals
One analysed run per company. Compact by default.
Alerts
Whether a run emailed the VC, and why.
Leads
Same inbox as
/leads in the app.Interactive playground
Every endpoint in this tab is generated from the OpenAPI 3.1 document. Paste a key in the playground to call production:GET /api/v1/openapi.