> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inploi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Kombo integration

> How inploi reaches certain applicant tracking systems through the Kombo unified API instead of building a direct integration.

[Kombo](https://docs.kombo.dev/ats/introduction) is a **unified ATS API**. Instead of building and maintaining a separate integration for every applicant tracking system (ATS), inploi integrates once with Kombo and reaches a range of ATSs through a single standardised interface. Kombo normalises each ATS's data model, so reading jobs from one enterprise ATS looks the same as reading them from another.

inploi uses Kombo where a direct integration is not available or not worthwhile to build and maintain. From the customer's point of view the experience is identical to a direct integration — the difference is in how inploi connects behind the scenes.

<Note>
  This is internal-facing reference material for Sales, Customer Success, and Engineering. It describes how inploi connects to certain ATSs, not something a customer configures themselves.
</Note>

## When inploi uses Kombo

inploi reaches these ATSs through Kombo rather than directly:

| ATS                          | Notes                                                                                                                                 |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Eploy**                    | Also integrated directly for some customers — see the two Eploy rows in the [capability matrix](/integrations/ats/capability-matrix). |
| **SAP SuccessFactors**       | Enterprise ATS reached through Kombo's unified interface.                                                                             |
| **Workday**                  | Enterprise ATS reached through Kombo's unified interface.                                                                             |
| **Oracle Recruiting family** | Handled through Kombo with ATS-specific parsers for certain customers.                                                                |

The definitive list of what each of these supports is the [capability matrix](/integrations/ats/capability-matrix). Kombo-reached integrations appear there with a **Via Kombo** transport.

## How it works

A Kombo-routed integration follows the same integration models as a direct one — the requests just go to the Kombo API, keyed by a per-customer Kombo integration ID rather than to the ATS directly.

<Steps>
  <Step title="Jobs are read through Kombo">
    inploi retrieves vacancies from the ATS via Kombo's unified jobs endpoints and imports them the same way as any other [job import](/integrations/ats/job-import).
  </Step>

  <Step title="Workflows are read and parsed">
    Where the ATS exposes an application workflow, inploi reads it through Kombo and parses it into inploi's own workflow structure so it can be rendered on the careers site. See [application workflow sync](/integrations/ats/workflow-sync).
  </Step>

  <Step title="Applications are submitted through Kombo">
    Completed applications are posted back through Kombo to the ATS, with attachments (such as CVs) included. See [submitting applications](/integrations/ats/application-submissions).
  </Step>

  <Step title="Field names are normalised">
    inploi maps common candidate fields — name, email, phone, and address — onto the canonical keys Kombo expects, so answers land in the right place regardless of how the source form labelled them.
  </Step>
</Steps>

## ATS-specific parsers

Kombo standardises most of the data, but some ATSs still need customer- or vendor-specific handling — for example the Oracle Recruiting family. inploi maintains dedicated parsers for these cases so that jobs, workflows, and applications map correctly. Where a Kombo-reached integration needs one of these parsers, it is built and maintained by inploi as part of the integration.

<Snippet file="ats-managed-integration.mdx" />

## Telling a Kombo integration apart from a direct one

* In the [ATS integrations register](/integrations/ats/ats-integrations#documentation-register) and the [capability matrix](/integrations/ats/capability-matrix), the transport column reads **Via Kombo**.
* The same ATS may be reachable both directly and via Kombo (as with Eploy), and the two can support different models — always check which transport a given customer is on before quoting a capability.
* For partner detail on a Kombo-reached ATS, start from the [Kombo documentation](https://docs.kombo.dev/ats/introduction) and the specific integration page (for example [SAP SuccessFactors](https://www.kombo.dev/integrations/successfactors)), then cite the source.

## Related pages

<CardGroup cols={2}>
  <Card title="ATS integrations register" icon="table-list" href="/integrations/ats/ats-integrations">
    Transport model and partner documentation links per ATS.
  </Card>

  <Card title="Capability matrix" icon="table-cells" href="/integrations/ats/capability-matrix">
    What each Kombo-reached integration supports.
  </Card>
</CardGroup>

<Snippet file="contact-support.mdx" />