New source connector: SAP SuccessFactors (OData v2 API)

[Diwakar Gupta (Diwakar-Gupta)]

Connector type

New API source connector - to be built with the Connector Builder / low-code YAML CDK.

Summary

There is currently no Airbyte source connector for SAP SuccessFactors HCM. SuccessFactors is one of the most widely deployed HR/HCM platforms in the enterprise market (core HR, Employee Central, Recruiting, Onboarding, Performance & Compensation), and its absence is a recurring gap - it's been asked about on the SAP Community forum with no existing answer pointing to a native Airbyte connector.

I have hands-on SuccessFactors experience (Employee Central, Onboarding, and Recruiting modules, admin-level access) and access to both a production-style and a sandbox tenant, where I've validated both Basic Auth and OAuth 2.0 (SAML Bearer Assertion) against the OData v2 API directly. I'd like to build this connector and would appreciate early feedback on scope and a couple of design questions before I start.

Proposed design approach: use-case streams, not raw entities

Rather than exposing each OData entity as a separate 1:1 stream, I'd like to model streams around the data shape a customer actually wants - since several core entities are tightly interrelated and rarely useful independently. For example, "employee details" naturally spans three entities (EmpEmployment, User, EmpJob) that have no real standalone analytical value on their own.

OData v2 supports this natively via $expand and $select, letting a single request pull a denormalized, ready-to-use record. Example, tested against a live tenant:

GET /odata/v2/EmpEmployment?
    $format=json
    &$top=4
    &$expand=jobInfoNav/companyNav,jobInfoNav,personNav,userNav,userNav,jobInfoNav/managerUserNav,jobInfoNav/departmentNav,jobInfoNav/divisionNav,jobInfoNav/locationNav
    &$select=jobInfoNav/companyNav/name,jobInfoNav/companyNav/externalCode,personIdExternal,userId,startDate,endDate,originalStartDate,seniorityDate,lastDateWorked,assignmentClass,isECRecord,okToRehire,jobInfoNav%2FjobCode,jobInfoNav%2FjobTitle,jobInfoNav%2Fcompany,jobInfoNav%2FbusinessUnit,jobInfoNav%2Fdepartment,jobInfoNav%2FmanagerId,jobInfoNav%2FstartDate,jobInfoNav%2FseqNumber,userNav%2FuserId,userNav%2Fusername,userNav%2FfirstName,userNav%2FlastName,userNav%2Fmi,userNav%2FdefaultFullName,userNav%2Femail,userNav%2Fstatus,userNav%2Flocation,userNav%2Fmanager,jobInfoNav/managerUserNav/email,jobInfoNav/managerUserNav/displayName,jobInfoNav/departmentNav/name,jobInfoNav/departmentNav/externalCode,jobInfoNav/divisionNav/name,jobInfoNav/divisionNav/externalCode,jobInfoNav/locationNav/name

This returns one denormalized "Employee Details" record per employee: identity (name, email, status, location), employment facts (start/end dates, assignment class), and current job (title, department, division, manager). I've confirmed this shape works against the live OData API; I haven't yet confirmed the declarative CDK's $expand/$select handling supports a query this nested as static request-options config, or whether it needs a custom component - that's one of my open questions below.

Proposed streams for v1

Stream	Underlying entities	Why a customer would sync it
Employee Details	EmpEmployment + userNav, jobInfoNav (+ nested managerUserNav, departmentNav, divisionNav, locationNav)	The core "who works here, what's their job, who's their manager" record. This is the anchor dataset almost every HR/workforce analytics, org chart, or identity-sync use case is built on — and it's far more useful pre-joined than as three separate normalized streams a customer has to stitch together themselves downstream.
Job Requisition	JobRequisition	Open and historical job requisitions (role, department, status, hiring manager). Lets talent-acquisition teams report on time-to-fill and open headcount without manual exports from the Recruiting module.
Job Application	JobApplication	Candidate applications tied to a requisition (stage, status, application date). Combined with Job Requisition, this is the basis for recruiting funnel/conversion reporting (applied → interviewed → offered → hired).

EmpJobRelationships (matrix/secondary manager relationships) is a natural follow-up stream once the pattern above is validated and reviewed — leaving it out of v1 to keep the first PR reviewable.

I'm intentionally leaving Compensation out of scope for now and focusing on getting the core pattern (auth, pagination, the "Employee Details" composite stream) right first.

Proposed authentication

OAuth 2.0 using a Bearer access token obtained via the SAML Bearer Assertion flow. The SAML signing/exchange would happen outside the connector (it doesn't map cleanly onto a static declarative auth block); the connector itself would use a standard Bearer Token authenticator with a token supplied by the user. Basic Auth is deprecated by SAP and being phased out, so I'd treat it as a documented fallback only, not the primary method.

Pagination

OData's native __next link (returned in the response body) rather than manually constructing offsets — this is SAP's own recommended mechanism and avoids relying on offset math the API doesn't guarantee is stable.

Incremental sync

$filter on lastModifiedDateTime for entities that expose it, so customers aren't forced into full refreshes on every sync.

Open questions for maintainers

1. Composite/denormalized streams vs. one-stream-per-entity — is the "Employee Details" approach above (one stream built from $expand/$select across 3 entities) consistent with how Airbyte connectors are typically modeled, or is there a strong preference for 1:1 entity-to-stream mapping that I should follow instead? Happy to go either way, just want to align before building.
2. Custom/extension fields — SuccessFactors is highly configurable, and most real tenants have custom MDF fields beyond the standard schema. Standard fields only would simplify v1 significantly, but may not be sufficient for many customers. Is a standard-fields-only v1 acceptable, with custom-field support (likely needing a discover-time metadata lookup so customers can pick which custom fields to sync) as an explicit fast-follow?
3. Filtering at the API level — e.g. syncing only active employees via $filter, rather than pulling all records including terminated/inactive ones. Should this be a configurable connector option in v1, or is that better left to downstream transformation?
4. Auth approach — given the SAML Bearer Assertion flow doesn't fit the Declarative OAuth Connector Specification, is a user-supplied Bearer token acceptable for v1, with full automated OAuth handling as a later improvement?
5. Any existing partial work, design discussions, or prior (possibly rejected) attempts at a SuccessFactors connector I should know about before starting?

Happy to share sanitized sample request/response payloads from my test tenant if useful for review.

[Airbyte Support Bot (airbyte-support-bot)]

Hi Diwakar Gupta (@Diwakar-Gupta), thank you for this incredibly thorough and well-researched proposal! The level of detail here — validated auth flows, tested OData queries, a clear stream design rationale — is really impressive.

We've escalated this to our internal team for review. A few thoughts on your open questions while they take a look:

1. Composite/denormalized streams vs. 1:1 entity mapping — Both patterns exist in the Airbyte connector ecosystem. The team will be able to provide guidance on which approach best fits the maintainability and usability goals for this connector.

2. Custom/extension fields — A standard-fields-only v1 with custom-field support as a documented fast-follow is a reasonable approach. The team can advise on the preferred pattern for handling dynamic schema discovery.

3. Filtering (e.g., active employees only) — This is a good design question. The team can weigh in on whether API-level filtering should be a v1 config option or left to downstream transformation.

4. Auth approach — A user-supplied Bearer token for v1, with the SAML Bearer Assertion flow documented as a follow-up, sounds pragmatic given the complexity of the SAML exchange. The team will confirm whether this is acceptable.

5. Prior work — We didn't find any existing connector work or prior attempts for SAP SuccessFactors in the repository, so this would be a net-new contribution.

We'll follow up once the team has reviewed the design proposal. In the meantime, if you have any additional questions about the Connector Builder or the low-code CDK, the Connector Builder documentation and the low-code CDK reference are good resources.

---

Need more help? Join Airbyte Community Slack for peer support, or if you're a Cloud customer, open a support ticket referencing this URL.

[Airbyte Support Bot (airbyte-support-bot)]

This discussion has been escalated to our internal team for review: https://github.com/airbytehq/oncall/issues/12983