BILL Spend & Expense (formerly Divvy) API
Two public surfaces coexist: the Spend & Expense REST API on the BILL v3 platform and the legacy Divvy GraphQL API, both token-authenticated with sandboxes and webhooks. The split surface and the 2025 id to uuid migration are the main integration tax.
Frequently asked questions
BILL Spend & Expense (formerly Divvy) scores C on the API Report Card. Two public surfaces coexist: the Spend & Expense REST API on the BILL v3 platform and the legacy Divvy GraphQL API, both token-authenticated with sandboxes and webhooks. The split surface and the 2025 id to uuid migration are the main integration tax.
BILL Spend & Expense (formerly Divvy) has an official API, but teams routinely hit its limits: gated access, partial coverage, or paid tiers. Most end up supplementing it with exports or an unofficial API layer like Supergood. Site terms may apply to any integration approach, and how they apply is a determination each team makes for itself.
BILL Spend & Expense, historically and still commonly known as Divvy, is the spend-management, corporate-card and expense product line of BILL Holdings (NYSE: BILL).
Vertical: Travel & Expense (with strong adjacency to Corporate Card issuing, Spend Management and Accounts Payable via the broader BILL platform). Issue physical and virtual Mastercard corporate cards to employees, vendors and one-time use cases. Set pre-approved budgets with hard spending limits, MCC restrictions and per-card velocity controls.
Large and growing in SMB/mid-market spend management. As of Q1 FY2025 BILL reported approximately 39,500 Spend & Expense customers (adding ~1,800 net new in the quarter), with Spend & Expense revenue of $138M in Q1 FY25 (+21% YoY) on 22% card-volume growth.
Cards: uuid, last4, masked PAN, status (active/frozen/cancelled), type (virtual/physical/vendor), holder, budget assignment, MCC group restrictions, velocity limits.
Divvy was founded in 2016; ~10 years old as of 2026.
Grades measure one thing: can a customer's engineering team get their own data out programmatically? We check six things (whether a real API exists, how access is gated, data coverage, auth quality, docs and developer experience, and stability) and roll them into a letter grade. Grades get re-verified, and they only move on evidence.