.png)
OneLogin Integration Guide
Connect OneLogin workforce identity data and selected event notifications with enterprise applications through REST APIs, OAuth 2.0, and Martini workflows.
OneLogin integration options at a glance
OneLogin’s primary enterprise integration mechanism is its regional REST API, which supports administrative resources such as Users, Applications, Roles, Groups, Events, and Mappings. API access uses OAuth 2.0 credentials and bearer tokens, with permissions assigned to each API credential. OneLogin also supports event webhooks for selected lifecycle, authentication, provisioning, and administrative events, while documented bulk user operations support migrations and large-scale changes. Martini can consume these APIs, receive webhook notifications through an exposed API or workflow, map identity data, apply validation and business rules, and coordinate scheduled reconciliation with checkpoints, throttling, retries, and downstream updates.
| Integration point | Supported by OneLogin? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Manage and query Users, Applications, Roles, Groups, Events, Mappings, and related administrative resources. Operations include retrieval, updates, deactivation, filtering, and synchronization. | Martini can consume OneLogin REST endpoints, handle regional base URLs, paginate collections, transform responses, and orchestrate downstream API calls. |
| Webhooks / outbound callbacks | Limited | Receive selected lifecycle, authentication, provisioning, and administrative event notifications for near-real-time processing. | Martini can expose an API or webhook workflow, validate and normalize notifications, deduplicate event identifiers, and retrieve the authoritative OneLogin object when the event is not a complete snapshot. |
| Bulk / async / batch APIs | Limited | Process bulk user changes for initial loads, migrations, and large-scale lifecycle updates. Coverage and semantics vary by endpoint. | Martini can orchestrate documented bulk user operations or use paginated REST calls with batching, checkpoints, throttling, retries, and validation. |
| Authentication | Yes | Obtain regional OneLogin API access tokens through OAuth 2.0 client credentials and use bearer tokens on administrative API calls. | Martini can store client credentials in protected configuration, request and reuse time-limited tokens, refresh them after expiration, and prevent secrets or tokens from entering logs. |
| Scheduled synchronization | Yes | Reconcile Users, Events, Applications, Groups, Roles, or Mappings and recover from missed event notifications. | Martini can schedule workflows, persist timestamps or identifiers as checkpoints, process pages, and coordinate bounded retries and recovery. |
| Events API | Yes | Query audit and activity records and identify authentication, provisioning, lifecycle, or administrative changes since a prior checkpoint. | Martini can classify Events, retrieve current objects where required, forward normalized events, and advance checkpoints only after successful processing. |
| File / attachment APIs | Not confirmed | No general-purpose file or attachment mechanism was confirmed for OneLogin identity resources. | Martini should use OneLogin REST APIs and documented event mechanisms rather than assuming a file-based exchange. |
| Database access | Not confirmed | OneLogin is a managed SaaS platform and direct database access is not a documented integration mechanism. | Martini can synchronize through documented APIs and event mechanisms instead of direct database connectivity. |
How OneLogin exposes data and business events
OneLogin REST APIs
OneLogin REST APIs are the primary administrative integration interface for Users, Applications, Roles, Groups, Events, Mappings, and related resources. They support resource-specific operations, filters, pagination, and regional endpoints.
Martini implementation pattern
Martini implementation pattern: configure the regional OneLogin base URL and OAuth token endpoint, obtain a bearer token, call the required resource endpoints, process paginated responses, map the results, and invoke downstream APIs from a workflow.
Implementation sequence
OneLogin Event Webhooks
OneLogin supports webhook notifications for selected lifecycle, authentication, provisioning, and administrative events. Coverage is event-specific, and a notification may not contain a complete current object.
Martini implementation pattern
Martini implementation pattern: expose a controlled Martini API or webhook workflow, validate the incoming request, preserve the event identifier, classify the event, and call the OneLogin REST API for authoritative object state before forwarding or applying the change.
Implementation sequence
OneLogin Events API
The Events API provides audit and activity records that can support incremental synchronization, security monitoring, and recovery from missed webhook notifications.
Martini implementation pattern
Martini implementation pattern: schedule a workflow that queries Events after the last successful checkpoint, classifies each event, retrieves current resource state when necessary, and advances the checkpoint only after downstream processing succeeds.
Implementation sequence
OneLogin Bulk Operations
OneLogin documents bulk user operations for migrations and large-scale lifecycle changes. Resource coverage and operation semantics vary by endpoint.
Martini implementation pattern
Martini implementation pattern: use a documented bulk user operation where appropriate, otherwise orchestrate paginated REST calls in bounded batches with validation, throttling, checkpoints, and retry handling.
Implementation sequence
Common OneLogin integration patterns
Pattern 1: Synchronize OneLogin users to ServiceNow
When to use this pattern
Use this pattern when ServiceNow must reflect workforce identity creation, updates, group membership, or deactivation. Webhooks or Events API polling reduce latency, while scheduled reconciliation provides protection against missed notifications.
Integration direction
Example Mapping
| OneLogin Field | Canonical Field | Target Field |
|---|---|---|
| OneLogin user_id | externalIdentityId | ServiceNow user ID |
| OneLogin email | primaryEmail | |
| OneLogin status | identityStatus | active |
| OneLogin department | department | department |
Martini implementation pattern
A Martini workflow receives a supported event or retrieves Events, fetches the current User, validates required attributes, applies deactivation rules, and calls ServiceNow APIs. Stable OneLogin identifiers provide idempotency; transient failures are retried and missed changes are recovered through reconciliation.
Martini capabilities used
- workflows
- API consumption
- API exposure
- data mapping
- business rules
- error handling
Pattern 2: Align OneLogin access with Salesforce
When to use this pattern
Use this pattern when Salesforce user status or access assignments should reflect OneLogin workforce attributes, Groups, Roles, or Applications. The design should distinguish OneLogin access from Salesforce licenses and permission sets.
Integration direction
Example Mapping
| OneLogin Field | Canonical Field | Target Field |
|---|---|---|
| OneLogin user_id | identityId | Salesforce Federation ID |
| OneLogin login | username | Salesforce username |
| OneLogin group membership | accessGroup | permission assignment |
| OneLogin status | lifecycleStatus | User.IsActive |
Martini implementation pattern
Martini retrieves Users and relevant assignments through event-driven or scheduled flows, maps them to Salesforce user and permission models, excludes protected service accounts, and applies controlled updates. Validation, duplicate detection, and retry limits prevent accidental access changes.
Martini capabilities used
- workflow orchestration
- REST API consumption
- data mapping
- conditional routing
- validation
- retry handling
Pattern 3: Route OneLogin security events
When to use this pattern
Use this pattern when authentication, administrative, provisioning, or lifecycle events must reach a SIEM, ticketing platform, or notification service for monitoring and response.
Integration direction
Example Mapping
| OneLogin Field | Canonical Field | Target Field |
|---|---|---|
| OneLogin event_id | eventId | external event ID |
| OneLogin event_type | eventType | alert category |
| OneLogin user_id | subjectIdentityId | affected user |
| OneLogin created_at | occurredAt | event timestamp |
Martini implementation pattern
Martini receives selected webhook events or queries the Events API, validates and normalizes the payload, enriches it with current OneLogin data when required, and forwards it. Event identifiers are retained for deduplication, while sensitive identity data is minimized in logs.
Martini capabilities used
- API exposure
- webhook intake
- data transformation
- validation
- deduplication
- monitoring
Pattern 4: Reconcile OneLogin identities during migration
When to use this pattern
Use this pattern for an initial migration, periodic reconciliation, or controlled coexistence with Workday, Microsoft 365, Google Workspace, or another identity source.
Integration direction
Example Mapping
| OneLogin Field | Canonical Field | Target Field |
|---|---|---|
| OneLogin user_id | sourceIdentityId | external ID |
| OneLogin first_name | givenName | first name |
| OneLogin last_name | familyName | last name |
| OneLogin group_id | groupMembership | group membership |
Martini implementation pattern
Martini processes paginated or documented bulk user operations in bounded batches, applies attribute transformations and matching rules, stages activation changes, and persists checkpoints. Conflicts, rate limits, invalid records, and partial failures are isolated for controlled recovery.
Martini capabilities used
- scheduled workflows
- batch processing
- pagination
- mapping and transformation
- checkpointing
- error handling
Applications commonly integrated with OneLogin
OneLogin commonly participates in workforce identity, access governance, application provisioning, and security-monitoring architectures. Martini can orchestrate OneLogin APIs and selected event notifications with the APIs of adjacent applications, while keeping mappings, checkpoints, validation, and recovery logic in reusable workflows.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Align Salesforce users and access assignments with workforce identity attributes, lifecycle status, groups, or roles. | OneLogin → Martini → Salesforce | Receive supported OneLogin events or run scheduled reconciliation, retrieve the authoritative User and relevant assignments, map identity attributes, and call Salesforce APIs with idempotent create-or-update and controlled deactivation logic. |
| ServiceNow | Synchronize employee identities and access status with IT operations while routing identity events into service workflows. | OneLogin → Martini → ServiceNow | Process OneLogin webhook notifications or Events API results, retrieve current User data when required, map users and groups, and invoke ServiceNow APIs with deduplication, retry handling, and reconciliation. |
| Microsoft 365 | Coordinate workforce account lifecycle, SSO-related administration, and account status across Microsoft cloud applications. | OneLogin → Martini → Microsoft 365 | Use OneLogin Users, Groups, and lifecycle information as inputs to a Martini workflow, transform attributes to the Microsoft 365 model, and apply staged activation or deactivation through supported target APIs. |
| Google Workspace | Synchronize workforce accounts and support coordinated identity lifecycle processes across Google applications. | OneLogin → Martini → Google Workspace | Run event-driven updates for supported changes and scheduled reconciliation for completeness, validate required account fields, and submit repeatable create, update, or suspend operations. |
| Workday | Use worker lifecycle data to drive identity creation, updates, and deactivation in OneLogin and downstream applications. | Workday → Martini → OneLogin | Consume worker changes from the available Workday integration surface, normalize them in Martini, validate matching and employment status rules, then call OneLogin APIs with checkpointed processing and exception handling. |
| Jira | Control Jira access according to OneLogin groups, roles, and workforce status while keeping user status aligned. | OneLogin → Martini → Jira | Retrieve current OneLogin Users and group or role information, apply access policies in a Martini workflow, and invoke Jira APIs using stable identifiers and idempotent updates. |
How to build a OneLogin integration in Martini
Objective
Configure the OneLogin regional API and token endpoints, API credential permissions, and protected runtime settings without embedding secrets in workflow logic.
Instructions in Martini
- Store the client ID and client secret in protected Martini secrets or environment configuration.
- Set the OneLogin regional API base URL and OAuth token endpoint.
- Request OAuth 2.0 bearer tokens and reuse valid tokens where appropriate.
- Confirm the credential has permissions for each required resource and operation.
Objective
Select the event, schedule, or API-led entry point that matches latency and completeness requirements.
Instructions in Martini
- Expose a Martini API or webhook workflow for selected OneLogin events.
- Use a scheduler to query Events or reconcile resource collections.
- Combine event-driven processing with scheduled reconciliation when missed events matter.
- Define the event, timestamp, or page checkpoint strategy.
Objective
Obtain the authoritative OneLogin object or collection needed for the business operation.
Instructions in Martini
- Call the relevant Users, Applications, Roles, Groups, Events, or Mappings endpoint.
- Follow pagination until the intended collection is complete.
- Retrieve the current object after an event when the notification is not a full snapshot.
- Use documented bulk user operations for suitable migrations or large changes.
Objective
Orchestrate retrieval, enrichment, decisions, target calls, and checkpoint updates as a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, transformation, and delivery logic into clear workflow stages.
- Apply bounded concurrency and throttling for large synchronizations.
- Route unsupported event types and invalid records to explicit exception handling.
- Advance checkpoints only after successful downstream processing.
Objective
Convert OneLogin identity and access data into the target application’s model while protecting data quality.
Instructions in Martini
- Map stable OneLogin identifiers rather than relying only on names or email addresses.
- Validate required target fields and distinguish inactive, suspended, and deleted states.
- Normalize Groups, Roles, Applications, and memberships to the target access model.
- Minimize sensitive identity data in logs and operational payloads.
Objective
Apply idempotent changes to the target system and make failures observable and recoverable.
Instructions in Martini
- Use create-or-update behavior where supported by the target API.
- Protect service accounts and apply explicit deactivation policies.
- Retry transient network, rate-limit, and temporary authorization failures within limits.
- Preserve failed-operation context for replay without exposing credentials.
Common OneLogin data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Users | Synchronize workforce identity profiles, status, directory association, role assignments, and provisioning attributes. | ServiceNow, Salesforce, Microsoft 365, Google Workspace, Jira | Martini retrieves Users through paginated or bulk-capable API flows, validates required fields, maps attributes, and applies idempotent create, update, suspension, or deactivation rules. |
| Applications | Represent enterprise applications configured for SSO, provisioning, or access management. | ServiceNow, Salesforce, Jira, Microsoft 365, security platforms | Martini can retrieve Applications, correlate assignments or configuration metadata, and route normalized changes to downstream APIs. |
| Roles | Represent permission or application-assignment groupings used to govern access. | Salesforce, Jira, cloud access systems, governance platforms | Martini maps role identifiers and assignments to target permission models, applying explicit policy and conflict rules. |
| Groups | Organize Users for access management, provisioning, and lifecycle processing. | ServiceNow, Salesforce, Google Workspace, Jira | Martini synchronizes membership changes, resolves stable identifiers, and uses reconciliation to detect missed updates. |
| Events | Capture administrative, authentication, provisioning, and lifecycle activity for synchronization or monitoring. | SIEM platforms, ServiceNow, notification systems, audit stores | Martini consumes webhook notifications or queries Events, preserves event identifiers, enriches incomplete events, and advances checkpoints after successful delivery. |
| Mappings | Define rules that assign roles, applications, or attributes based on User properties. | Identity governance stores, downstream access systems, audit platforms | Martini can retrieve and normalize Mappings, apply equivalent downstream business rules, and validate the resulting access decisions. |
Authentication and security considerations
OAuth 2.0 API authentication
OneLogin administrative APIs use API credentials to obtain regional OAuth 2.0 bearer tokens. The credential permissions determine which resources and operations are available.
Secrets and regional configuration
Store the client ID, client secret, regional API base URL, and token endpoint in protected Martini environment configuration or secrets management. Do not embed credentials or bearer tokens in workflow logic or logs.
Identity data protection
- Minimize user and event fields passed between systems.
- Restrict access to workflows that process identity and security data.
- Validate webhook requests according to the verification capabilities available for the OneLogin tenant.
- Protect audit and authentication event data from excessive logging.
Operational considerations for OneLogin integrations
Pagination and checkpoints
Collection endpoints may be paginated. Process all required pages and persist a checkpoint only after successful handling of the corresponding data.
Rate limits and retries
Use bounded concurrency, throttling, backoff, and retry limits for large synchronizations. Separate transient failures from permanent authorization or validation errors.
Event completeness
OneLogin webhook coverage is selected rather than universal. Combine event-driven processing with scheduled reconciliation when missed changes would create material risk.
Idempotency and object consistency
Use stable OneLogin identifiers and deduplication keys. Treat an event as a change signal unless it contains sufficient state, then retrieve the authoritative User, Group, Role, or Application.
Schema and lifecycle handling
Validate required attributes and distinguish inactive, suspended, and deleted states. Test mappings when OneLogin attributes, target schemas, or access policies change.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini keeps OneLogin authentication, retrieval, transformation, business rules, downstream API calls, checkpoints, and exception paths in coordinated workflows rather than scattered scripts.
Reusable integration assets
API consumption, webhook intake, mappings, validation, and error handling can be organized into reusable integration logic for multiple identity and enterprise applications.
Reliable synchronization
Martini supports event-driven, scheduled, paginated, and batch-oriented designs so teams can combine low latency with reconciliation and recovery.
Maintainable change management
Explicit mappings, protected configuration, controlled retries, and observable workflow outcomes make identity integrations easier to test, operate, and adapt than point-to-point implementations.
Frequently asked questions
OneLogin can be integrated through its regional REST APIs, OAuth 2.0 bearer-token authentication, selected event webhooks, Events API queries, and documented bulk user operations. REST APIs manage resources such as Users, Applications, Roles, Groups, Events, and Mappings, while scheduled reconciliation can supplement event-driven processing.
Yes. Martini can consume OneLogin REST APIs, obtain OAuth 2.0 tokens, receive selected OneLogin event webhooks through an exposed API or workflow, and orchestrate mappings, validation, synchronization, and downstream updates.
No. A dedicated OneLogin connector is not required. Martini can use OneLogin’s confirmed native integration mechanisms, including REST APIs, OAuth 2.0 authentication, selected event webhooks, Events API queries, and documented bulk user operations.
Lonti does not charge an additional per-connector or per-vendor fee to integrate OneLogin. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from OneLogin, cloud infrastructure, or other third-party services based on subscription, usage, and deployment model.
Use the REST API as the primary mechanism for administrative resources and OAuth 2.0 for API authentication. Use webhooks for supported lower-latency events, the Events API for incremental processing and audit use cases, and bulk or paginated operations for migrations and reconciliation.
Yes, OneLogin documents event webhooks for selected lifecycle, authentication, provisioning, and administrative events. Coverage is event-specific, so Martini workflows should validate the event type and retrieve the current OneLogin object when the notification is not a complete snapshot.
A Martini workflow can process webhook events, query the Events API, or run scheduled REST API reconciliation. It retrieves authoritative Users or other objects, maps them to the target model, uses stable identifiers for idempotency, and advances a timestamp or event checkpoint only after successful processing.
Martini can distinguish OAuth, authorization, rate-limit, transient network, validation, missing-object, and duplicate-event failures. Workflows can apply bounded retries and backoff, persist event identifiers, isolate invalid operations, and retain enough context to replay failed business actions without exposing secrets.
Related Martini documentation
Connect OneLogin with Martini
Use Martini to orchestrate OneLogin APIs and selected event notifications with enterprise applications through secure, maintainable, and observable integration workflows.