How to set up SAP SuccessFactors credentials

SAP SuccessFactors does not use a standard OAuth consent flow, so there is no OAuth app for you to create on Apideck's side and no client ID/secret for you to hold. Authentication is OAuth2 SAML2-Bearer Assertion: each connection carries credentials that were registered inside that consumer's own SuccessFactors tenant, and Apideck mints the access tokens from them.

Two things are on your plate as the application owner:

1. Enable the connector and make sure your onboarding tells each consumer's SuccessFactors administrator what to register (section 1 and 2 below).
2. Only if you need a brand-new SAP demo/test tenant of your own: apply for SAP PartnerEdge (section 3). If your consumers already have a SuccessFactors test instance from their own SAP contract — most do — that instance connects like any other and no partnership is needed.

1. Enable the connector (no shared client credentials)

Enable SAP SuccessFactors in the Apideck Dashboard for the Unified API you build against — one SuccessFactors connection serves both:

• HRIS (Employee Central): platform.apideck.com/configuration/hris/sap-successfactors
• ATS (Recruiting): platform.apideck.com/configuration/ats/sap-successfactors

There is no Use your own client credentials step for this connector. Credentials are sourced from the connection itself, so every connection is bring-your-own — there is no Apideck-managed SuccessFactors client that connections can fall back to.

What Apideck does with those credentials: it builds a SAML assertion naming the connection's user, signs it with the registered X.509 private key, and exchanges it at https://{api_server}/oauth/token for a bearer token. You do not sign or refresh anything yourself.

No redirect or callback URL is involved. This flow is server-to-server: there is no browser redirect and no consent screen, and the consumer enters credentials in a Vault form instead. If a SuccessFactors registration screen insists on an application URL, any URL the administrator controls is fine — SuccessFactors never calls it in this flow.

2. Prepare your consumer onboarding

Each consumer's SuccessFactors administrator registers an OAuth client application with an X.509 certificate in their own tenant, then supplies five values in Vault:

Vault field	What it is
API server	The tenant's API data-center hostname (e.g. apisalesdemo8.successfactors.com)
Company ID	The tenant's company ID
Username	The SuccessFactors-internal userId (not a username or email address) of the technical/service user the connection runs as. It must exactly match the userId entered in the client application's Bind to Users field — see the note below the table.
Client ID	The API key generated during the client-application registration
Client secret	The private key of the X.509 key pair whose public certificate was registered — the full contents of the .pem file. Recommended: generated with the administrator's own tooling, uploading only the public certificate during registration. Also supported: generated inside the registration screen itself and downloaded at that time — this works too, but exposes the private key to the SuccessFactors UI.

Decide the user before registration. The userId is entered twice — once in Bind to Users during registration, and again as the Vault Username — so the technical/service user has to be chosen before the administrator opens the registration screen. Note also that this is the SF-internal userId, which is not necessarily the value shown as a username or login name: the authoritative way to look it up is Integration Center (SAP KBA 3156552). The value in the user's profile panel is often the same, but that is not guaranteed on every tenant, so treat Integration Center as the source of truth. Every API call on the connection runs with that user's permissions.

Recommended: generate the key pair outside SuccessFactors. Have the administrator create the X.509 key pair with their own tooling and upload only the public certificate during registration, keeping the private key on their side to paste into Vault. SuccessFactors also supports generating the certificate inside the registration screen and downloading the private key at that time — this works too, but widens the private key's exposure, so recommend the own-tooling route where the administrator has a choice.

Two points worth putting in your own onboarding material, because they are the usual cause of a stalled connection:

• The administrator doing the setup needs Admin Center access sufficient to reach and use the Manage OAuth2 Client Applications screen. Without it, the screen simply is not visible to them.
• It is one screen and one step. Registering the client, pasting the X.509 certificate, and binding the user all happen on Manage OAuth2 Client Applications (reachable from Admin Center's Action Search, and also surfaced as API Center > OAuth Configuration for OData — the same screen under a second name, so an admin following older SAP notes still lands in the right place). The step that gets missed is the Bind to Users checkbox — sometimes labelled Bind to Technical User — and its User ID field: tick it and enter the SuccessFactors userId of the technical/service user the connection will run as (the same value that goes in the Vault Username field), then save. If no user is bound, ordinary business (interactive) users can still request tokens, but a technical/service user cannot, and SAP returns Unable to generate token. User is not bound to the client application. Since most production connections deliberately run as a dedicated service user, tell your consumers to bind it up front. HRIS resources require the Employee Central module; ATS resources require Recruiting.

Hand the consumer-facing connection guide for SAP SuccessFactors to that administrator rather than collecting the values over email — the client secret is a private key.

Test and production instances are separate registrations: each instance has its own API server, Company ID and OAuth client, and credentials are not interchangeable between them.

3. Apply for SAP PartnerEdge (only for a new demo/test tenant)

Skip this section unless you need SAP to provision a new demo or test tenant for your own development — for example because you have no consumer instance to build against yet. Connecting a consumer's existing live or test instance does not require any partnership.

Getting a brand-new SuccessFactors test/demo tenant requires certified SAP partner status, which runs through SAP PartnerEdge. The application is in two stages.

Stage 1 — Apply for Open Ecosystem

1. Sign in to SAP PartnerEdge. You can create a new account if you don't have one.
2. Fill out the company details and go to the next step.
3. Fill out the contact details and go to the next step.
4. Select Open Ecosystem specialization and go to the next step.
5. Submit the form. SAP reviews the application before you can proceed to the Build track — ask your SAP contact for an expected timeline.

Stage 2 — Apply for SAP PartnerEdge Build

Precondition: you already have an Open Ecosystem partnership account.

Before you start, be aware of what the Build track assesses, so you apply once rather than twice: a go-to-market-ready solution, an Application Readiness Check (ARC) that reviews your solution's architecture, an annual business plan, and recommended workforce roles (sales/presales, marketing, technical, and a partner cloud architect).

1. Sign in to SAP PartnerEdge.
2. Navigate to Partnership > Development > SAP PartnerEdge Build and follow the steps. (SAP also links the form directly from the SAP PartnerEdge Build program page; navigate from the Partner Portal if a direct form link no longer resolves.)
3. Fill out the company details and go to the next step.
4. Fill out the contact details and go to the next step.
5. Fill out answers to these questions about your solution:
   • Solution Description - A brief description of what your application does.
   • Is your solution ready? - Yes/No.
   • Which support options do you offer to your customers? - List all means of contact customers can use, such as email addresses, contact forms, phone numbers, etc.
   • Do you own the intellectual property of this solution? - Yes/No.
   • Does your solution connect, integrate, or exchange data with an SAP cloud service via API calls? - Yes.
   • Have you implemented the Application Interface Key in the API header of these API calls? - No.
   • Would your customers be able to use the bundled SAP cloud services or software without your solution? - Answer "Not applicable."
   • Do you have a Test & Demo and/or Development License? - Yes/No.
   • Does your solution require mandatory certification by the SAP Integration and Certification Center? - No.
   • Architecture Diagram - Upload or provide a link to your architecture diagram and how your system communicates with SAP.
   • Solution Demo - A video recording explaining how your application works and deals with SAP data.
   • Marketing Materials - Your solution marketing materials, such as PDFs or webpages.
   • Additional Information - Anything you think is important for SAP to review your application.
6. Submit the form, then ask your SAP partner contact where to track its status and what review timeline to expect, rather than planning around a fixed one.

FAQ and troubleshooting

Do we need an SAP partnership before we can go live? No. A consumer connecting their own existing SuccessFactors instance needs nothing from SAP's partner program — their administrator registers the OAuth client in their own tenant. PartnerEdge only comes into play when SAP has to provision a new demo/test tenant.

Do we need to store or rotate a client secret? No — Apideck holds no application-level SuccessFactors credentials. The private key lives on the connection, and the consumer's administrator can revoke it at any time by deleting the Client Application in their tenant. That takes effect for new tokens immediately, but Apideck may keep operating on an access token it already holds for up to 24 hours, until its next refresh attempt fails. Delete the Vault connection as well if access has to stop inside that window.

Do we have to handle token refresh? No. For background: the signed SAML assertion Apideck generates is valid for 10 minutes, and the access token it returns is valid for 24 hours. Apideck always requests a fresh token, which matters because SuccessFactors otherwise returns the same still-valid token instead of issuing a new one.

Something else? Contact Apideck Support.