Summary and recommendation
Stonly does not publish a public REST API, developer documentation portal, or confirmed SCIM endpoint as of the research date.
All user lifecycle operations - create, update, deactivate - are UI-only.
SSO via SAML (Okta, Entra/Azure AD) is referenced in IdP catalogs for the Enterprise plan, but automated provisioning through those connectors is not confirmed by any official Stonly source.
Any API or SCIM surface that may exist is undocumented and likely gated behind Enterprise contracts;
treat all capabilities as unverified until confirmed directly with Stonly.
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 publicly documented webhook system for user-management events found in official Stonly documentation.
Alternative event strategy: No documented alternative found.
SCIM API status
- SCIM available: No
- SCIM version: Not documented
- Plan required: Enterprise
- Endpoint: Not documented
Limitations:
- No public SCIM endpoint documented in official Stonly help center or developer docs.
- SSO is gated to the Enterprise plan; SCIM provisioning support is not confirmed in any official public source.
- Okta and Entra (Azure AD) SSO integrations are referenced in community/IdP catalogs, but SCIM provisioning via these connectors is not confirmed by Stonly's own documentation.
Common scenarios
No documented API endpoints, auth methods, scopes, rate limits, or pagination schemes are available for Stonly user management.
Webhook support for user-lifecycle events is also absent from official documentation.
Because no public API surface exists, integration scenarios that would typically cover provisioning, deprovisioning, role sync, or audit log export cannot be constructed from available data.
Teams evaluating Stonly for programmatic identity management should treat the current state as API-absent and plan accordingly.
Scenario implementations are not yet verified for this app.
Why building this yourself is a trap
The core trap with Stonly in an identity graph context is the gap between IdP catalog presence and actual provisioning capability. Okta and Entra list Stonly SSO integrations, which can create a false signal that SCIM provisioning is also available - it is not confirmed.
Without a verified SCIM endpoint, Stonly cannot participate in automated joiner/mover/leaver flows, meaning it will appear as a dark spot in any identity graph that relies on SCIM-sourced account state.
An MCP server with 60+ deep IT/identity integrations can surface this gap at the orchestration layer, but it cannot manufacture a provisioning API that does not exist; the resolution path is direct vendor confirmation or Enterprise contract review.
Automate Stonly 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.
