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.
Start here if you want to compare local tool evidence with vendor-admin reports: FleetView. Vendor-API attribution supplies its vendor-reported usage block.
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. The rows remain labeled as vendor evidence.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 authenticate direct requests to the named vendor API. They do not enter the stored rows or 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.
Read more
Last updated