Skills API Integrations: A Guide to HRIS and LMS Skills Data

Skills data is becoming an increasingly valuable, but also complex dataset in enterprise HR. A company decides which skills it recognizes, rates employees against them, attaches expected levels to roles, and tags learning content with the skills it teaches. Those four things usually sit in two or three systems, each with its own model.

The result is a growing category of products that need to exchange this data with an HRIS or LMS. Skills intelligence platforms, role profile vendors, assessment providers, learning platforms, and internal mobility tools all depend on the same underlying objects. Without an integration, the default is often a monthly employee CSV, which leaves skill profiles and recommendations stale.

This guide is for product and engineering teams building customer-facing integrations with Workday, SAP SuccessFactors, Oracle HCM, and enterprise learning platforms.

Read the following guide to learn about:

• The core objects: Skill catalogs, employee ratings, role expectations, and course skill tags
• Use cases: How skills, assessment, learning, and mobility products use skills data
• The landscape: Which HRIS and LMS platforms hold skills data
• System capabilities: What you can typically read and write in each system
• Data models: How skills, scales, ratings, roles, and course tags are structured
• Implementation: Direct integrations, embedded iPaaS, and unified APIs
• Getting started: Scope, auth, attribution, sync, and identity matching

Skills API integrations at a glance

• There are four main objects: the skill catalog, employee proficiency ratings, role skill expectations, and course skill assignments.
• The primary systems of record are HRIS platforms: Workday, SAP SuccessFactors, and Oracle HCM typically own the catalog, employee profile, or role architecture.
• Learning systems model skills differently: An LMS commonly attaches skills to learning content and sometimes to learners, but those skills often use a different taxonomy, proficiency scale, or attribution model than the HRIS.
• The valuable direction is often outbound: many products need to push a curated catalog, external assessment rating, or role profile back into the customer’s system.
• The main integration challenge is normalization: proficiency scales, sources, permissions, write paths, and tenant configuration vary by system.

What is a skills API integration?

A skills API integration is a connection between a product and the HRIS or LMS where a customer’s skills data lives. It lets the product read or write one or more of four objects: the skill catalog, employee proficiency ratings, role skill expectations, and skills attached to learning content.

Skills integrations are more write-heavy than most HR integrations. The valuable direction is often outbound: pushing a curated taxonomy, a verified rating, or a role profile back into the customer’s system of record, so other HR modules can use it.

The four objects in a skills integration

Skill catalogs

The catalog is the set of skills a company recognizes. Each skill has an identifier and name, and may carry a proficiency scale, category, description, aliases, or source attribution.

Employee proficiency ratings

A rating connects an employee to a skill at a level. It also needs a source: self-assessment, manager rating, expected level, inferred result, or external assessment. The same employee can have more than one rating for the same skill when those ratings come from different sources.

An expected-level rating on the employee can also act as a per-person override of the role’s default expectation. For example, a software engineer role may expect Python at level 3, but one employee’s expected level can be set to 4 without changing the role itself.

Role skill expectations

An expectation attaches a skill and target level to a job, position, or another staffing object. It describes what the role requires, not what a person currently has.

Course skill assignments

An LMS commonly attaches skills to a course or course revision. This describes what the content teaches. It does not automatically prove that a learner has reached a particular proficiency level. Sometimes, courses also have topics that serve the same purpose of describing the content.

Top skills API integration use cases

Skills inference and talent intelligence

Platforms that derive skills from work signals read the HRIS catalog, employee records, performance reviews, job descriptions, and learning activity, then write a per-employee skill profile back.

A consistent requirement in this group is control over attribution. These products often want the LMS’s automatic “completed a course, therefore has the skill” behavior disabled because the inference model is the product they sell and an automatic tag creates poor data.

Examples: TechWolf, SkyHive, Lightcast, Beamery, SeekOut

Role and job architecture profiles

Taxonomy vendors build a skill profile per role and keep it synced with the HCM where the roles live. In the implementations we have scoped, a role profile is typically 15 to 35 skills.

One vendor in this space had built a native Workday integration that touched six specific API calls against a small set of fields, then wanted to hand off the per-system work entirely. Its engineers needed to focus on labor-market data rather than Workday version changes.

Examples: Lightcast Talent Transform, 365Talents, Cobrainer, Neobrain

Assessment and certification write-back

Assessment providers hold a graded result and need it on the employee record with correct attribution. This is where the LMS model can run out. A course is complete or incomplete, while an “expert” result normally belongs in an HRIS skill rating.

One assessment vendor discovered this difference partway through scoping, having assumed the LMS could store the level its product produces.

Examples: Workera, Codility, HackerRank, TestGorilla

Learning personalization and completion write-back

Learning platforms read employee skills to decide which content to surface, then write completions and scores back so compliance reporting remains in the customer’s system. Reading course skill assignments from the customer’s own LMS matters too, since the recommendation engine needs to know which skills a course teaches.

Examples: Degreed, Docebo, Cornerstone, 360Learning, OpenSesame

Internal mobility and workforce planning

Matching a person to an internal opening requires employee ratings and role expectations at the same time, plus the org structure to know who approves the move.

Without an integration, these platforms often ask HR to upload employee CSVs monthly. The result is stale data and low trust in the recommendations. One internal mobility vendor told us integration coverage became a gate in enterprise deals once HCM suites started shipping their own mobility features.

Examples: Gloat, Fuel50, 365Talents, Eightfold, Reejig

Compensation and workforce analytics

A growing set of innovative providers reads verified skills to segment compensation benchmarks by capability or run strategic workforce planning against the skill distribution of the organization.

Examples: Workleap, ChartHop

Why teams are building skills integrations now

Much of this traces back to the “skill-based organization” idea, which has been strongly advocated for by Workday and others. It argues that jobs, pay, and mobility should be organized around verified skills rather than static job titles.

To support this and manage skills, Workday built its Skills Cloud, SAP SuccessFactors has Talent Intelligence Hub and Growth Portfolio, and Oracle offers Dynamic Skills. Enterprise buyers now have a place to maintain skills data, and they increasingly expect specialist vendors to integrate with it.

A talent platform that cannot write into Workday or SAP is competing against a module its prospect may already pay for. This makes integration coverage often a mandatory requirement in enterprise deals.

Which systems hold skills data?

Skills data lives in different modules and at different levels of detail. HCM suites commonly separate the enterprise taxonomy, employee proficiency, and role requirements. Learning systems may attach skills to content. The exact surface depends on the modules a company licenses, its release version, and how the tenant is configured.

Skills API capabilities by HRIS

The following matrix describes the integration surfaces teams most commonly scope. Availability is typically tenant- and module-dependent.

Please note that SAP SuccessFactors skills access currently requires the integrating vendor to be certified as an SAP skills partner.

Key skills API integration concepts

Proficiency scales vary by system and sometimes by skill

A skill rating of 3 means nothing without its scale. Some systems use a numeric range with a defined step; others use ordered named levels such as Beginner, Intermediate, and Expert.

The scale can differ between two skills in the same catalog, so it should travel with the skill rather than being configured once per connection. Kombo models this as a proficiency_scale: either NUMERIC, with a minimum, maximum, and step, or SINGLE_SELECT, with ordered options. Options are ranked rather than assigned invented numbers.

Rating source and provider attribution matter

A self-assessment, manager rating, and external assessment result are all ratings, but products displaying a skill need to tell them apart. Kombo exposes a source such as SELF, MANAGER, EXPECTED, or EXTERNAL, plus a rating provider.

Writing an external rating can have a prerequisite: the HRIS may not accept an externally sourced result until the provider is registered in the tenant. Kombo handles this through connection settings so registration happens once rather than on every request.

Role expectations live on staffing or profile objects

An expected level typically attaches to the role, not the person, except for the per-employee override described above, where an expected-level rating is set directly on that person. Depending on the system, that role may be represented as a job, position, or job profile.

The behavior differs sharply by system. In SAP, writing an expectation at a higher level of the job architecture can affect the jobs beneath it. Integrations should surface that scope explicitly rather than allow a broad change to happen silently.

Managed skills require reconciliation

Some HRIS platforms may not simply store the exact skill name a third party sends. Workday can match submitted skills against its managed taxonomy and retain attribution to the source. Other systems only accept customer-defined skills directly.

In practice, teams take one of three approaches:

• Rely entirely on the system’s existing taxonomy
• Layer a curated taxonomy on top of the customer’s existing one and reconcile the two
• Push a fully custom taxonomy

The first two are the most additive and the most common: write curated skills alongside what the customer already has, then keep pulling customer changes and reconciling them. Fully replacing the customer’s taxonomy has inconsistent support across systems and is usually very complex.

Course skill assignments do not automatically prove proficiency

An LMS skill assignment describes content. In a normalized course model, it is usually a reference with an ID, remote ID, and name. Deriving a level from completion, assessment, or learning activity is work the application must do. The resulting rating can then be written to the HRIS with the appropriate source.

Learning outcomes and competencies may require a native API

Learning outcomes and SAP-style competencies do not always fit a unified course model. They may require scope-gated remote data or a passthrough to the platform’s native API. SAP SuccessFactors Learning, for example, exposes additional LMS data through its own OData surfaces.

Skills API data models

Skill catalog object

A skill represents an entry in the customer’s catalog. It carries its own proficiency scale, timestamps for change detection, and a soft-deletion marker.

{
  "id": "3f1c9a2e-...",
  "remote_id": "SKILL-4821",
  "name": "Kubernetes",
  "proficiency_scale_id": "9f2c41b7-...",
  "proficiency_scale": {
    "type": "SINGLE_SELECT",
    "ordered_options": [
      { "id": "a1...", "remote_id": "1", "name": "Awareness" },
      { "id": "a2...", "remote_id": "2", "name": "Working" },
      { "id": "a3...", "remote_id": "3", "name": "Expert" }
    ]
  },
  "remote_created_at": "2025-11-02T09:14:00Z",
  "changed_at": "2026-06-30T11:02:41Z",
  "remote_deleted_at": null,
  "custom_fields": {},
  "integration_fields": {}
}

Employee skill proficiency rating

A rating joins an employee to a skill at one level and records the source of the claim.

{
  "id": "7b20...",
  "employee_id": "c4e8...",
  "skill_id": "3f1c9a2e-...",
  "proficiency": {
    "type": "SINGLE_SELECT",
    "selected_option_id": "a3..."
  },
  "source": "EXTERNAL",
  "rating_provider_id": "d91f...",
  "changed_at": "2026-07-14T08:31:12Z"
}

Role skill expectation

An expectation attaches the target level to the staffing entity that represents the role.

{
  "staffing_entity_id": "5aa1...",
  "skill_id": "3f1c9a2e-...",
  "expected_level": {
    "type": "SINGLE_SELECT",
    "selected_option_id": "a3..."
  }
}

Course skill assignment

On the LMS side, skills sit inside a course revision. The assignment identifies what the content teaches without assuming an employee proficiency.

{
  "id": "8kG9...",
  "revisions": [
    {
      "id": "4Kd2...",
      "course_id": "8kG9...",
      "title": "Kubernetes Fundamentals",
      "remote_url": "https://customer.lms.example/course/8412",
      "status": "ACTIVE",
      "skill_assignments": [
        {
          "skill": {
            "id": "26vafvWSRmbhNcxJYqjCzuJg",
            "remote_id": "skill-12345",
            "name": "Kubernetes"
          }
        }
      ]
    }
  ]
}

Full field references are in the skills endpoint documentation, skill proficiency ratings documentation, and courses endpoint documentation. For enterprise systems with both HRIS and LMS modules, the user source is usually the same, and ID matching is easier. For other cases, such as UKG Pro as HRIS and 360Learning as LMS, an SSO-based approach with external identifiers may be utilized, or a work email fallback. Kombo’s SSO and identity matching guide covers this in more detail.

Approaches for implementing skills API integrations

In-house development

Building direct is reasonable when one system and one direction cover the product’s foreseeable requirements. A native integration provides full control over platform-specific behavior and lets a team use every field the vendor exposes.

It becomes more challenging with the second and third system. Skills modules are among the newer and faster-moving parts of HCM suites, so the team must maintain system expertise, tenant setup guides, version changes, and customer-specific behavior over time.

Best for: one strategic integration, deep native functionality, and a team prepared to own maintenance.

Embedded iPaaS

An embedded iPaaS provides flexible workflows and mapping without requiring every connector to be built from the transport layer upward. It can work well when each customer’s flow differs or when the required objects already exist in the platform.

It does not remove the need to understand how each HR system models catalogs, scales, attribution, or roles. The team still designs and maintains one mapping per system, often in a workflow environment outside its core codebase.

Best for: highly customized customer workflows and broad automation beyond one normalized data model.

Unified API

A unified API gives the product one schema across systems, with system-specific behavior handled beneath it. For skills, that means one skill object whether the scale is numeric or option-based, one rating object across attribution models, and one write path across supported HRIS platforms.

The trade-off is coverage. A unified model should expose the common objects cleanly and provide remote data, custom fields, or passthrough when a native field does not belong in the shared schema.

Kombo built its HRIS skills model by working through read and write requirements together with a design partner. That is why the scale travels with the skill and provider registration is handled automatically. Writes to the catalog go through POST /hris/skills and are reverse-synced, so a large taxonomy push can be queued and reconciled without the product managing each customer’s rate limits directly.

Best for: customer-facing products that need the same skills workflow across multiple HRIS or LMS platforms.

Getting started with skills APIs

Work through these questions before building:

Which object do you actually need?

Catalogs, employee ratings, role expectations, and course tags are four separate scopes. Products often assume they need all four, but turn out to need just one or two.

Which direction should data move?

Decide which system is authoritative for each object. A product may read the customer catalog, generate ratings, and write only the external rating back.

How should ratings be attributed?

If the product is the authority on a rating, plan for provider registration and confirm how the target system distinguishes external, manager, self, and inferred results.

How will you handle scales?

The UI and database need to support numeric and ordered-option scales without assuming that every customer uses 1 to 5.

What is the sync strategy?

Use delta filters where available and keep a full reconciliation path for connectors that require it. Nested LMS revisions may change even when the parent course appears stable.

How will identities be matched?

Prefer ID-based matching where the HRIS and LMS share user identifiers, and confirm whether work email is a reliable fallback where they do not. Define fallback behavior for aliases, rehires, and multiple employments.

Which modules and permissions are required?

Skills APIs can depend on licensed modules, security domains, tenant settings, and external provider configuration.

Can you obtain sandbox access?

Enterprise HCM tenants are often the long pole. Getting a representative Workday, SAP, or Oracle environment can take much longer than writing the first API call.

What is the fan-out cost?

Estimate sync work per employee or learner, not only per catalog or course. Some LMS platforms expose progress through user-level requests.

Kombo’s HRIS and LMS APIs use REST, one authentication model, cursor pagination, and normalized rate limiting across systems. Skills coverage changes quickly, so confirm the live connector coverage before committing to a specific system in a customer deal.

FAQ