Summary and recommendation
Bill.com does not expose a public user management API. There are no documented REST endpoints for creating, updating, listing, or deactivating users programmatically.
SCIM 2.0 is listed as available on the Enterprise plan, but the endpoint URL, supported operations, and implementation details are not publicly documented - access requires direct engagement with Bill.com support or sales. A third-party provisioning path exists via OneLogin, but this is an IdP-specific integration, not a general-purpose API.
Developers should treat Bill.com as an API-dark app for user lifecycle operations until vendor documentation is published.
API quick reference
| Has user API | No |
| SCIM available | Yes |
| SCIM plan required | Enterprise |
Authentication
Auth method: Not documented
User object / data model
User object field mapping is not yet verified for this app.
Core endpoints
Endpoint coverage is not yet verified for this app.
Rate limits, pagination, and events
Rate limits: Not documented
Rate-limit headers: Unknown
Retry-After header: Unknown
Rate-limit notes: Not documented
Pagination method: Not documented
Default page size: Not documented
Max page size: Not documented
Pagination pointer: Not documented
Webhooks available: Unknown
Webhook notes: Not documented
Alternative event strategy: Not documented
SCIM API status
- SCIM available: Yes
- SCIM version: 2.0
- Plan required: Enterprise
- Endpoint: Not documented
Limitations:
- Native SCIM not publicly documented
- SSO via SAML available on enterprise plans
- OneLogin provides third-party provisioning
- Contact vendor for SCIM options
Common scenarios
Given the absence of a public user API and the opacity around SCIM, the practical automation scenarios are narrow. The most viable path for teams needing lifecycle automation is through an MCP server with ~100 deep IT/identity integrations, which can bridge Bill.
com's SCIM endpoint - once provisioned at the Enterprise tier - to a broader identity orchestration layer without requiring custom connector development.
Outside of that pattern, automation is limited to what the OneLogin provisioning integration supports, which is IdP-scoped and not portable to other orchestration tooling. There are no documented webhooks, no event stream, and no API-based method to detect or react to user state changes in real time.
Scenario implementations are not yet verified for this app.
Why building this yourself is a trap
The primary trap with Bill.com's API surface is assuming SCIM availability implies a standard, self-serve integration.
The SCIM 2.0 flag is accurate in principle, but with no public endpoint, no documented supported operations, and no published attribute mapping, teams that build automation assumptions into their identity stack before confirming Enterprise SCIM access will hit a hard wall.
A secondary trap is the OneLogin provisioning integration: it is a point solution tied to one IdP and does not generalize to other orchestration tooling, including an MCP server with ~100 deep IT/identity integrations.
Any team evaluating Bill.com for programmatic user management should get written confirmation of SCIM endpoint availability, supported operations, and attribute schema before committing to an integration architecture.
Automate Bill.com workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
