SAP SuccessFactors Employee Central with the OData v2 entities used by this import available in your instance.
An administrator with Manage Integration Tools > Manage OAuth2 Client Applications permission and permission to manage Role-Based Permissions (RBP).
A dedicated API user and its exact User ID, plus your Company ID.
The API server hostname for the correct environment and data center. Use the API endpoint, not the browser login URL.
Agreement with the Skriba team on the employee population and fields to import.
Create an RSA private key and matching X.509 certificate using your organization’s approved tools. Use a secure signature algorithm, such as SHA-256 with RSA.
Keep the private key secure. Register only the public certificate in SuccessFactors. Coordinate certificate expiry and rotation with the Skriba team. If rotation introduces a new key pair, update the private key used by Skriba at the same time. Renewing a certificate with the same key pair does not by itself require a different private key. Test authentication after either change.
Open Admin Center > API Center > OAuth Configuration for OData > Register Client Application. Alternatively, search for Manage OAuth2 Client Applications.
Enter Skriba Employee Import as the application name.
Enter an approved Application URL identifying the integration. This is an identification URL, not the API server URL or an OAuth callback URL.
For a dedicated business/API user, enable Bind to Users and enter that user’s exact User ID to restrict the client to that user. SAP’s system-generated technical users have different binding rules; confirm those rules with your administrator if using one.
In X.509 Certificate, paste only the Base64 certificate content between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. Omit those two marker lines. Do not paste the private key.
Choose Register, then View the registered application and record its API Key. Skriba uses this value as the Client ID.
Create a permission role for the dedicated API user and assign the agreed target population. Configure entity and field view permissions for the data below, including access needed for the related objects expanded by the query.
For Employee Central person and employment data, use the appropriate User Permissions > Employee Central Effective Dated Entities and User Permissions > Employee Data permissions for query access. Also configure the relevant read permissions for department, job-code, picklist, and User data. Exact fields and permission labels depend on the customer’s configuration.
Do not grant editable API permissions, upsert/import permissions, or unrelated administrative access.
Read-only does not automatically mean restricted access. The administrative Employee Central HRIS OData API (read-only) permission allows querying all HRIS objects. Do not use it as a substitute for restricted field and population access without explicitly agreeing that broader access. Verify the effective access of the API user.
The import queries EmpJob and related employment, person, personal-information, email, department, job-code, manager, picklist, and User records.
Data area | Fields requested |
|---|---|
Person and personal information | Person ID, first name, last name, gender, date of birth, place of birth |
Email address and email-type code | |
Employment | Start date, original start date, end date |
Job | Department code and German name, job title, German job-code name, contract type, regular/temporary code, FTE |
Manager and User | Manager User ID and full name, employee status, direct and total team sizes |
The current query uses a fixed field list, including contractType, departmentNav/name_de_DE, and jobCodeNav/name_de_DE. Confirm that these properties exist in your tenant. If a field is unavailable or outside the agreed scope, coordinate a query change with the Skriba team before enabling the import; changing the destination mapping alone does not change which fields are requested.
The query requests contractType, originalStartDate, and email-type code, but the current importer does not expose these as fields for destination mapping. It uses employmentNav/startDate as the employment start date. For email, it takes the first returned record with an email address represented as a string; it does not use email-type code to select a business address. Confirm that this selection meets your requirements.
The current importer requires Person ID, first name, last name, and gender to retain a returned employee record. It filters User status to t or f and employment end date to empty or later than the date three months before the import runs. Confirm that this matches the intended population.
Provide the following through the agreed secure channel:
API server base URL, for example https://api2.successfactors.eu. Supply only the HTTPS hostname, optionally followed by /; do not append /odata/v2, /oauth/token, query parameters, or a port.
API User ID of the dedicated user.
Company ID for the same SuccessFactors environment.
API Key / Client ID from the registered OAuth application.
Matching RSA private key in PEM format, transferred through the agreed secret-sharing mechanism. Agree the exact PEM key format with the Skriba team before transfer and verify compatibility during the connection test; PEM alone does not specify the key encoding or whether it is encrypted.
Never send the private key in ordinary email or a support ticket. Confirm the secure transfer method with the Skriba team before sharing it.
With the Skriba team:
Save the credentials and test authentication.
Fetch a sample using the actual employee query to verify field availability and read permissions.
Check that returned employees and fields match the approved scope, including inactive or recently departed employees where applicable.
Verify field mappings, dates, FTE, department/job labels, manager information, and the selected email address before enabling imports. Include an employee with multiple email records when available.
A successful authentication test alone does not verify data permissions or field compatibility.
Reviewed October 12, 2026 against SAP documentation and Skriba main commit 0ffc443b. Not validated against a live customer tenant.
