.png)
Leapsome Integration Guide
Integrate Leapsome with HR, identity, reporting, and workforce systems through its REST API, SCIM provisioning, and scheduled Martini workflows.
Leapsome integration options at a glance
Leapsome provides a public REST API for accessing platform data such as Users, Teams, Goals, Reviews, Surveys, and Learning modules. SCIM is available for supported provisioning scenarios, including user creation, attribute updates, and deactivation, and should be treated separately from the general REST API. A general-purpose webhook facility, GraphQL API, SOAP API, bulk API, file API, SDK, and direct database access were not confirmed. Martini can consume Leapsome APIs from scheduled or API-triggered workflows, store API keys securely, paginate and batch requests, map data to downstream systems, apply validation and business rules, and expose normalized Leapsome data through a controlled API.
| Integration point | Supported by Leapsome? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Read Users, Teams, Goals, Reviews, Surveys, and Learning modules, and perform supported employee or platform-data operations. Exact endpoints, writable fields, and permissions depend on the tenant and API version. | Martini can consume the Leapsome REST API from workflows, map and validate payloads, paginate collections, apply business rules, and expose normalized results to other applications. |
| SCIM provisioning | Yes | Provisioning-oriented lifecycle operations such as creating users, updating user attributes, and deactivating or removing users where enabled for the organization. | Martini can orchestrate surrounding HR or identity flows and call the supported SCIM interface while keeping provisioning logic separate from general REST API synchronization. |
| Authentication | Yes | The general Leapsome API documents API-key authentication using a bearer token in the HTTP Authorization header. SCIM uses a separate token-based configuration where enabled. | Martini stores API keys and provisioning tokens in secrets or protected environment configuration and injects them into outbound requests without embedding credentials in workflows. |
| Webhooks / outbound callbacks | Not confirmed | A general-purpose Leapsome webhook facility and complete event catalog were not verified. Changes to Users, Teams, Goals, Reviews, Surveys, or Learning modules should not be assumed to generate callbacks. | Martini can use scheduled REST polling, checkpoints, timestamps, external identifiers, and reconciliation logic when a suitable Leapsome callback is unavailable. |
| Bulk / async / batch APIs | Not confirmed | No separate official bulk or asynchronous API was confirmed. Large collections may still be processed through REST pagination and controlled workflow batches where endpoint behavior permits. | Martini can bound concurrency, process pages or batches, persist checkpoints, and retry transient failures without treating the REST API as a confirmed bulk interface. |
| GraphQL APIs | Not confirmed | No official Leapsome GraphQL API was confirmed in the available developer material. | Martini can consume GraphQL APIs generally, but a Leapsome integration should use the documented REST API unless the tenant provides separate GraphQL documentation. |
| SOAP APIs | No | No official Leapsome SOAP API was verified. | Martini can consume SOAP services generally, but SOAP should not be used as the assumed Leapsome integration mechanism. |
| File / attachment APIs | Not confirmed | No general-purpose Leapsome file or attachment API was confirmed. File exchange should be validated for the specific feature before design. | Martini can process files when a supported endpoint or external file exchange is available, but it should not assume Leapsome exposes a general file API. |
| Database / analytics access | No | No customer-facing direct Leapsome database connection was verified. Data access should use documented APIs or supported export facilities. | Martini can persist synchronization state in an approved database, while Leapsome data remains accessed through supported vendor interfaces. |
How Leapsome exposes data and business events
Leapsome REST APIs
Leapsome provides a public REST API for programmatic access to platform data. It is the primary confirmed mechanism for reading Users, Teams, Goals, Reviews, Surveys, and Learning modules, with exact endpoint availability and writable fields dependent on tenant configuration and permissions.
Martini implementation pattern
Martini implementation pattern: a scheduled or API-triggered workflow authenticates with a bearer API key, retrieves the required Leapsome resources, follows the endpoint-specific pagination model, validates and transforms the response, and writes the result to a target system or exposes it through a Martini API.
Implementation sequence
Leapsome SCIM provisioning
Leapsome supports SCIM-based provisioning for supported identity and HR environments. SCIM is focused on lifecycle operations such as user creation, attribute updates, and deactivation, rather than general platform data such as Goals or Surveys.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves lifecycle changes from an HR or identity source, validates the provisioning payload, invokes the supported Leapsome SCIM interface, and records the result for reconciliation. REST remains the appropriate mechanism for additional Leapsome platform data where supported.
Implementation sequence
Scheduled REST synchronization
A general-purpose Leapsome webhook facility and complete event catalog were not publicly confirmed. Scheduled polling is therefore the conservative approach for reliable change detection when callbacks are unavailable.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that queries relevant Leapsome endpoints, uses endpoint-supported filters or stored checkpoints, compares stable identifiers and timestamps where available, and sends only new or changed objects downstream. Periodic reconciliation detects missed updates or deactivations.
Implementation sequence
Common Leapsome integration patterns
Pattern 1: Synchronize HR employees to Leapsome
When to use this pattern
Use this pattern when Workday, BambooHR, HiBob, Personio, or SAP SuccessFactors is the source of employee identity and organizational data. It supports scheduled synchronization and, where enabled, provisioning-oriented lifecycle operations.
Integration direction
Example Mapping
| Leapsome Field | Canonical Field | Target Field |
|---|---|---|
| employeeId | employee.externalId | User external identifier |
| workEmail | employee.email | User email |
| displayName | employee.displayName | User display name |
| employmentStatus | employee.status | User active status |
Martini implementation pattern
Martini retrieves new and changed employees, validates required identity fields, maps the HR model to Leapsome Users, and chooses the supported REST or SCIM operation. Stable identifiers drive idempotent upserts, while deactivations, permission failures, and validation errors are recorded for reconciliation and replay.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- validation
- business rules
- secrets management
- error handling
Pattern 2: Synchronize identity lifecycle with Leapsome
When to use this pattern
Use this pattern when Okta or another identity source manages account creation, attribute changes, and deactivation, while Leapsome receives supported provisioning operations through SCIM.
Integration direction
Example Mapping
| Leapsome Field | Canonical Field | Target Field |
|---|---|---|
| id | identity.userId | SCIM user identifier |
| profile.email | identity.email | SCIM userName |
| profile.displayName | identity.displayName | SCIM display name |
| status | identity.lifecycleStatus | SCIM active |
Martini implementation pattern
Martini receives or retrieves lifecycle changes, validates identity uniqueness, maps the event to the SCIM representation, and calls Leapsome. It may call the REST API for additional platform-specific attributes when supported. Retries are bounded and provisioning outcomes are persisted for reconciliation.
Martini capabilities used
- API-triggered workflows
- API consumption
- data mapping
- validation
- conditional routing
- retry handling
Pattern 3: Publish Leapsome goals and reviews to reporting
When to use this pattern
Use this pattern when reporting or workforce-planning systems need normalized Goals and selected Reviews from Leapsome. The workflow can use reporting-period or update-window filters where the relevant endpoints support them.
Integration direction
Example Mapping
| Leapsome Field | Canonical Field | Target Field |
|---|---|---|
| goalId | performance.objectiveId | objective_id |
| ownerId | performance.employeeId | employee_id |
| progress | performance.progressPercent | progress_percent |
| reviewCycle | performance.reviewPeriod | review_period |
Martini implementation pattern
Martini polls the relevant REST endpoints, follows pagination, normalizes employee and team identifiers, applies reporting-period and privacy rules, and writes JSON or another approved representation to the reporting target. Checkpoints and source identifiers support replay, while malformed objects are isolated from successful loads.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination
- data transformation
- privacy rules
- checkpointing
- error handling
Pattern 4: Synchronize Leapsome engagement or learning data
When to use this pattern
Use this pattern when approved Survey or Learning module information must be delivered to analytics, HR reporting, or workforce-planning systems. It is appropriate when the downstream process requires controlled field selection and privacy filtering.
Integration direction
Example Mapping
| Leapsome Field | Canonical Field | Target Field |
|---|---|---|
| userId | engagement.employeeId | employee_id |
| surveyId | engagement.surveyId | survey_id |
| moduleId | learning.moduleId | learning_module_id |
| completionStatus | learning.status | completion_status |
Martini implementation pattern
Martini retrieves the supported Leapsome data, maps users and organizational units, removes fields not required by the downstream process, and sends the transformed result. The workflow retries transient failures, records completed transfers, and avoids duplicate delivery through stable object identifiers or checksums.
Martini capabilities used
- scheduled workflows
- API consumption
- data minimization
- mapping and transformation
- business rules
- idempotency
- retry handling
Applications commonly integrated with Leapsome
Leapsome is commonly positioned alongside HRIS, identity, and collaboration applications. The precise integration method, fields, and tenant capabilities should be confirmed with the customer’s Leapsome configuration. Martini can orchestrate these exchanges through documented APIs, SCIM where enabled, scheduled workflows, mappings, validation, and controlled error handling.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Workday | Synchronize worker profiles, employment status, managers, and organizational attributes with Leapsome. | Workday → Martini → Leapsome | Martini retrieves changed worker data, validates required attributes, maps the source model to Leapsome Users, and performs idempotent create or update operations through the appropriate REST or provisioning interface. Deactivations and rejected records are recorded for reconciliation. |
| BambooHR | Provision and maintain Leapsome Users from the HR system of record. | BambooHR → Martini → Leapsome | A scheduled Martini workflow retrieves employee changes, maps identifiers and employment status, and upserts Users or invokes the supported provisioning interface. Checkpoints, retries, and source-to-Leapsome ID mappings make repeated synchronization safe. |
| HiBob | Keep employee lifecycle and organizational data aligned with Leapsome. | HiBob → Martini → Leapsome | Martini consumes the available HR API, applies field and privacy rules, and sends only the required employee attributes to Leapsome. Validation failures are isolated while transient API errors are retried with bounded concurrency. |
| Personio | Synchronize employee records and employment changes into Leapsome. | Personio → Martini → Leapsome | Martini schedules incremental extraction from Personio, normalizes employee and organizational identifiers, and calls the applicable Leapsome REST or provisioning endpoint. The workflow stores checkpoints and routes persistent failures to an exception process. |
| SAP SuccessFactors | Connect enterprise employee and organizational data with Leapsome performance and engagement processes. | SAP SuccessFactors → Martini → Leapsome | Martini orchestrates the enterprise HR API exchange, transforms SuccessFactors worker data into Leapsome-compatible User attributes, and optionally retrieves selected Leapsome reporting data for downstream use. Access and sensitive-field rules are applied before transfer. |
| Okta | Automate identity lifecycle and provisioning into Leapsome where SCIM is enabled. | Okta → Martini → Leapsome | Martini can coordinate provisioning-oriented requests and surrounding HR data flows while the Leapsome SCIM interface handles supported lifecycle operations. The workflow validates identifiers, records provisioning outcomes, and reconciles deactivated users. |
| Slack | Deliver selected employee-experience, engagement, or workflow notifications to collaboration channels. | Leapsome → Martini → Slack | Martini periodically retrieves approved Leapsome data or receives an upstream request, applies privacy and audience rules, and publishes a controlled Slack message through the relevant Slack API. Exact Leapsome notification coverage must be verified. |
| Microsoft Teams | Deliver selected Leapsome notifications or employee workflows in Teams. | Leapsome → Martini → Microsoft Teams | A Martini workflow transforms selected Leapsome information into Teams-compatible messages, filters sensitive content, and invokes the Teams integration endpoint. Retry and duplicate controls prevent repeated notifications. |
How to build a Leapsome integration in Martini
Objective
Establish access to the Leapsome REST API or supported SCIM interface without embedding credentials in workflow definitions.
Instructions in Martini
- Create the required Leapsome API key or provisioning token.
- Store credentials in Martini secrets or protected environment configuration.
- Configure bearer-token authentication for the relevant outbound request.
- Use separate credentials and access permissions for development, testing, and production.
Objective
Select a trigger that matches the synchronization reliability required by the business process.
Instructions in Martini
- Use a scheduler when Leapsome callbacks are unavailable or unconfirmed.
- Use an API-triggered workflow when an upstream HR or identity system initiates the exchange.
- Define the schedule, scope, and checkpoint strategy before retrieving data.
Objective
Read the required Leapsome objects using documented REST endpoints or invoke supported SCIM lifecycle operations.
Instructions in Martini
- Call the endpoint for Users, Teams, Goals, Reviews, Surveys, or Learning modules as required.
- Validate the tenant’s endpoint availability, permissions, filters, and writable fields.
- Follow the endpoint-specific pagination model and avoid assuming a common updated-since parameter.
- Limit concurrency and capture relevant response metadata.
Objective
Coordinate retrieval, validation, transformation, target writes, and state management in a maintainable Martini workflow.
Instructions in Martini
- Separate extraction, transformation, business rules, and target delivery into clear workflow stages.
- Persist source identifiers, checkpoints, and synchronization outcomes.
- Route invalid objects and repeated failures to an exception or reconciliation process.
Objective
Convert Leapsome objects into the canonical model required by downstream systems while minimizing sensitive data.
Instructions in Martini
- Map stable Leapsome identifiers to canonical employee, team, performance, engagement, or learning fields.
- Normalize dates, status values, organizational identifiers, and reporting periods.
- Apply privacy filters and omit fields not required by the target.
Objective
Enforce tenant-specific validation, lifecycle, access, and reporting rules before writing data.
Instructions in Martini
- Validate required identity and object fields.
- Distinguish active, inactive, deactivated, and not-found users according to the target process.
- Apply reporting-period, audience, aggregation, and sensitive-data rules.
Common Leapsome data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Users | Employee profiles, account attributes, employment status, and identity synchronization. | Workday, BambooHR, HiBob, Personio, SAP SuccessFactors, Okta | Martini maps stable identifiers and required attributes, validates writes, performs idempotent upserts, and handles deactivation or reconciliation separately. |
| Teams | Organizational team membership and team-level structures. | HRIS platforms, identity systems, reporting stores | Martini normalizes team and employee identifiers, applies organizational rules, and synchronizes changes through supported REST operations where available. |
| Goals | Individual, team, and organizational objectives with progress information. | Data warehouses, reporting APIs, business applications | Martini retrieves Goals by available filters or pages, transforms progress data into a reporting model, and preserves source identifiers for repeatable loads. |
| Reviews | Performance review cycles, participants, and review-related information. | Reporting platforms, HR applications, workforce-planning systems | Martini retrieves only permitted fields, applies privacy and reporting-period rules, and routes sensitive data through restricted workflows and redacted logs. |
| Surveys | Employee engagement surveys and response-related information. | Analytics platforms, reporting stores, HR applications | Martini applies tenant-specific schema validation, minimizes sensitive fields, and transforms survey information into approved aggregate or detail outputs. |
| Learning modules | Learning content, assignments, and completion information. | HR reporting, workforce-planning, learning analytics systems | Martini retrieves supported module and completion data, maps users and organizational units, and retries transient transfers without duplicating completed outputs. |
Authentication and security considerations
API-key authentication
Leapsome’s general REST API uses an API key sent as a bearer token in the HTTP Authorization header. SCIM provisioning uses a separate token-based configuration where enabled.
Credential protection
Store Leapsome credentials in Martini secrets or protected environment configuration. Do not embed keys in workflows, mappings, source control, logs, or test payloads.
Least privilege and privacy
- Use the minimum administrative permissions required by the integration.
- Separate development, testing, and production credentials where possible.
- Minimize performance, survey, learning, and employee data transferred between systems.
- Use HTTPS and redact sensitive values from operational logs.
Operational considerations for Leapsome integrations
Rate limits and pagination
A definitive public Leapsome rate-limit value was not verified. Use bounded concurrency, avoid unnecessary reads, follow endpoint-specific pagination, and apply exponential backoff for HTTP 429 and transient 5xx responses.
Incremental synchronization
Do not assume that every endpoint supports a common updated-since filter. Store checkpoints, use supported timestamps or filters where available, maintain source-to-Leapsome identifiers, and run periodic reconciliation for missed changes and deactivations.
Idempotency and schema changes
- Upsert by stable vendor or external identifiers rather than display names.
- Make retries safe after network timeouts and separate request-sent from request-confirmed states when needed.
- Validate required fields and treat unknown response fields as nonfatal unless required.
- Test API and tenant configuration changes in a non-production environment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini centralizes API consumption, SCIM coordination, scheduling, mapping, validation, business rules, target delivery, and exception handling in maintainable workflows. This avoids duplicating synchronization logic across separate scripts and point-to-point integrations.
Reusable integration assets
Teams can expose normalized Leapsome data through controlled Martini APIs and reuse workflow stages for HR, identity, reporting, engagement, and learning processes. Environment configuration and secrets remain separate from implementation logic.
Operational control
- Use checkpoints, retries, bounded concurrency, and idempotent upserts.
- Monitor workflow outcomes and investigate repeated failures through structured logs.
- Apply privacy and field-minimization rules consistently across downstream integrations.
Frequently asked questions
Leapsome can be integrated through its public REST API for platform data such as Users, Teams, Goals, Reviews, Surveys, and Learning modules. Supported provisioning scenarios can use SCIM for user lifecycle operations. Because a general-purpose webhook facility was not confirmed, scheduled API synchronization is the conservative approach for many change-management use cases.
Yes. Martini can consume the Leapsome REST API from scheduled or API-triggered workflows, orchestrate supported SCIM exchanges, map and validate objects, handle pagination and retries, and expose normalized Leapsome data through a controlled API.
No. A dedicated Leapsome connector is not required. Martini can integrate using Leapsome’s confirmed REST API, API-key authentication, and supported SCIM provisioning interface, with workflows handling orchestration, transformation, validation, and error management.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Leapsome. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Leapsome, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
Use the Leapsome REST API for application data such as Goals, Reviews, Surveys, and Learning modules. Use SCIM for supported provisioning-oriented operations such as user creation, attribute updates, and deactivation. GraphQL and SOAP were not confirmed, and no separate bulk API was verified.
A publicly verified general-purpose webhook facility and complete event catalog were not confirmed. Integrations should not assume that changes to Users, Teams, Goals, Reviews, Surveys, or Learning modules generate callbacks. Martini can instead poll REST endpoints on a schedule and maintain checkpoints or reconciliation state.
Martini retrieves Leapsome objects, follows endpoint-specific pagination, maps them to a canonical model, applies validation and privacy rules, and writes them to the target system. Stable identifiers, checkpoints, timestamps where available, and periodic reconciliation help support incremental and repeatable synchronization.
The integration should classify authentication, validation, rate-limit, transient server, and not-found failures separately. Martini can apply bounded retries with backoff, limit concurrency, persist checkpoints, and use idempotent upserts based on stable identifiers. Repeated failures can be routed to an exception or dead-letter process for review.
Related Martini documentation
Leapsome API
Workflows
Plan your Leapsome integration with Martini
Connect Leapsome to HR, identity, reporting, and workforce applications through secure APIs, provisioning workflows, data mapping, and operational controls designed for enterprise integration.