Prove · Vendor-API attribution
Vendor-API attribution
What the tool vendors themselves say your team used. RepoOps captures most AI-tool activity locally, but some tools report usage only through their vendor's admin API. This feature pulls that report (bring your own admin key), stores it locally, and shows it beside the local evidence as its own labeled source. It never converts vendor usage into per-PR authorship: knowing a developer used Cursor heavily last week is real evidence about tool adoption, not proof any particular PR was AI-authored.
Where it surfaces
- FleetView: a “Vendor-reported usage” table inside AI tools in use, beside the install-probe and session evidence (
GET /api/tool-inventory, fieldvendorUsage) - AI share: a per-developer vendor-usage table under By developer, labeled “vendor API” (
GET /api/ai-share, fieldvendorEvidence); the tier percentages are untouched - Config & env doctor: an aggregator-keys panel showing configured or missing per vendor key
- Hosted FleetView: the team tool inventory carries per-tool vendor developer counts and last-activity dates (never identities)
The two vendor reads
CURSOR_ADMIN_KEY, RepoOps pulls per-developer per-day usage (active days, tab acceptances, composer, chat, and agent requests) for the last 30 days from api.cursor.com. This is the strongest vendor evidence: real counts per developer per day, straight from the vendor.COPILOT_METRICS_TOKEN and the org in COPILOT_METRICS_ORG, RepoOps pulls seat assignments (who holds a seat, when the vendor last saw them active, in which editor) and the org-level daily metrics (engaged users, code suggestions and acceptances). Copilot reports per-developer presence but only org-aggregate counts, and the surfaces say exactly that instead of pretending otherwise.Honesty contract
- Vendor usage never changes an AI-share percentage and never moves a PR between evidence tiers; precedence stays attested over co-authored over classified.
- No identity join is fabricated: Cursor rows key by email, Copilot rows by GitHub login, git history by author name. The tables show the vendor's own identities.
- No key means an honest empty state naming the missing variable, and zero outbound requests.
- Keys never leave the machine, never enter the stored rows, and never ride the hosted snapshot; the hosted twin carries counts and dates only.
How it runs
Pulls are scheduled (every 12 hours by default, tunable with REPOOPS_VENDOR_USAGE_PULL_HOURS) and available on demand via POST /api/vendor-usage/pull. Results land in a bounded local store (one snapshot per day, pruned to 90 days) under the RepoOps data directory, and reads deduplicate overlapping pull windows so nothing double-counts.