Summary and recommendation
Bombora exposes no user-management API surface. Its public developer API is scoped exclusively to B2B intent data - specifically Company Surge scores - and does not include endpoints for creating, updating, deactivating, or listing users. No SCIM API, no user provisioning webhooks, and no programmatic deprovisioning path are publicly documented.
Any user lifecycle automation would require a custom arrangement negotiated directly with Bombora's enterprise support team under contract.
API quick reference
| Has user API | No |
| SCIM available | No |
| 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: No
Retry-After header: No
Rate-limit notes: Not documented
Pagination method: none
Default page size: 0
Max page size: 0
Pagination pointer: Not documented
Webhooks available: No
Webhook notes: No webhook system for user-management events is publicly documented by Bombora.
Alternative event strategy: Bombora supports SSO via SAML 2.0 (Okta, Entra ID) for authentication; user lifecycle management must be handled manually through the Bombora platform UI or via the IdP's SSO session controls.
SCIM API status
- SCIM available: No
- SCIM version: Not documented
- Plan required: Enterprise
- Endpoint: Not documented
Limitations:
- No SCIM provisioning is documented or offered by Bombora as of the policy date.
- User provisioning is manual via the Bombora platform admin UI.
- SSO (SAML 2.0) is available for Okta and Entra ID but does not include automated SCIM provisioning.
Common scenarios
For teams using an MCP server with ~100 deep IT/identity integrations to automate provisioning across their stack, Bombora represents a hard gap: there is no API surface to target. SAML 2.
0 SSO is available for Okta and Entra ID, but this covers authentication only - session termination via the IdP does not trigger deprovisioning in Bombora. No webhook events for user-management actions are documented, eliminating event-driven automation as a fallback.
The only viable automation path is indirect: scripting against the IdP's SSO session controls, with the understanding that Bombora-side access is not revoked until manually actioned.
Scenario implementations are not yet verified for this app.
Why building this yourself is a trap
The core risk is assuming that SSO coverage equals lifecycle coverage - it does not for Bombora. A departed employee whose IdP account is disabled retains a Bombora platform record until a manual removal step is completed, creating a latent access exposure on a platform with access to proprietary B2B intent data.
No rate limit headers, no retry-after signals, and no pagination schema are documented because there is no user API to call. Engineering time spent attempting to build a provisioning integration here has no documented endpoint to target and would require undocumented, unsupported contract-specific arrangements.
Automate Bombora 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.
