Summary and recommendation
Jirav does not expose a public REST API for user management. No developer portal, API reference, or API key mechanism is documented in official Jirav sources as of the latest available data. All user lifecycle operations - inviting, role assignment, deactivation - are UI-only.
Authentication for end-users is handled via OAuth login (Google, Microsoft, Xero); this is a login-time flow only and does not expose programmatic provisioning. There are no documented endpoints, no scopes, no rate limit headers, and no webhook system for user events.
For teams building an identity graph across their SaaS stack, Jirav represents a hard gap: the platform cannot be queried or written to via API, and any identity data it holds is not extractable programmatically.
API quick reference
| Has user API | No |
| SCIM available | No |
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 documentation found in official Jirav sources.
Alternative event strategy: Jirav supports data integrations via direct connectors (QuickBooks, Xero, Google Sheets, Salesforce, etc.) for financial data, but no event-driven webhook system for user management is documented.
SCIM API status
- SCIM available: No
- SCIM version: Not documented
- Plan required: Not documented
- Endpoint: Not documented
Limitations:
- No SCIM support documented in official Jirav help center or product pages.
- SSO is limited to OAuth-based login via Google, Microsoft, and Xero; no SAML or SCIM provisioning documented.
- No Okta, Entra ID, OneLogin, or Google Workspace SCIM integration documented.
Common scenarios
No API integration scenarios are viable for Jirav user management given the absence of a public API. Automated provisioning on hire, role changes on team transfer, and deprovisioning on termination all require manual UI intervention.
Data integrations (QuickBooks, Xero, Google Sheets, Salesforce) are supported for financial data ingestion, but these are purpose-built connectors for FP&A workflows - they do not expose user or identity data and cannot be repurposed for access management automation.
If a future Jirav API becomes available, the minimum viable integration would require: an authenticated endpoint for listing users with roles, a write endpoint for invite and deactivate operations, and event webhooks or a polling mechanism for change detection. None of these exist today.
Scenario implementations are not yet verified for this app.
Why building this yourself is a trap
The core risk is invisible drift: because Jirav has no SCIM and no API, your identity graph will have no programmatic signal when a Jirav user's role changes or when an account goes dormant. Access reviews must be triggered manually and reconciled by logging into the UI directly.
The OAuth-only SSO model means you cannot enforce session termination or deprovisioning through your IdP. Revoking a user's Google or Microsoft account does not guarantee Jirav access is revoked - the platform's own session and account state is a separate, unlinked layer.
With no documented deactivation workflow and no API to audit current user state, Jirav is a blind spot in any automated joiner-mover-leaver process.
Teams relying on an MCP server with 60+ deep IT/identity integrations to orchestrate access across their stack will need a manual exception process specifically for Jirav until the vendor ships programmatic user management.
Automate Jirav 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.
