Description

The Apply API now supports OAuth 2.0 as an authorization method. This update enhances the security and flexibility of integrations by allowing the use of OAuth 2.0 authorization flows for accessing these APIs.

OAuth 2.0 authorization is now available for the following endpoints:

1. Create a New Candidate Application
   POST https://api.smartrecruiters.com/postings/{uuid}/candidates
   Required OAuth 2.0 Scope: candidate_applications_manage

2. Get Application Configuration for Posting
   GET https://api.smartrecruiters.com/postings/{uuid}/configuration
   Required OAuth 2.0 Scope: candidate_applications_manage

3. Get Candidate Status
   GET https://api.smartrecruiters.com/postings/{uuid}/candidates/{candidateId}/status
   Required OAuth 2.0 Scope: candidate_applications_manage

The previously available authorization methods remain unchanged and supported, ensuring backward compatibility and no breaking changes.

Impact

This change introduces an additional, more secure way to authenticate requests to the Apply API. Existing authorization methods continue to function as before, ensuring no breaking changes. Adopting OAuth 2.0 is optional but recommended for improved security.

References

• Apply API Guide
• Create a New Candidate Application
• Get Application Configuration for Posting
• Get Candidate Status

Description

Apply-api now returns also applicationId when created a new candidate application.

Impact

This is additional information added to the response.
This change is backwards compatible and does not require any changes in the existing clients.

References

• Create a New Candidate Application endpoint

Description

Introducing a new way to authenticate with SmartRecruiters APIs using the client_secret_basic OAuth client authentication method.

This change enables the method based on the client ID and client secret, which are sent in the Authorization header of the token exchange request.
This method can be used for the OAuth 2.0. Client Credentials and Authorization Code grants.

Impact

This change provides an additional way to authenticate with SmartRecruiters APIs using the client_secret_basic method.
This change does not affect existing authentication methods.

References

• OAuth 2.0. Client Credentials grant
• OAuth 2.0. Authorization Code grant

Description

Introducing our new public API - Message Templates API.
This API enables you to manage message templates within SmartRecruiters, allowing you to create, update, delete, and retrieve templates.
To use this API, you will need the following access scopes: message_templates_read or message_templates_write.

Impact

The Message Templates API empowers you to handle message templates in SmartRecruiters, providing similar functionality as the UI.

References

• Message templates api
• Access scopes

Description

We have launched a new API endpoint that allows users to retrieve detailed job criteria for each position. This feature delivers structured information, including specific criteria, related questions, and the workflow steps assigned to each job.

• GET /reviews-api/v201910/jobs/{jobId}/criteria

Impact

This feature will help standardize interviews and improve hiring consistency.

References

• Get job criteria

Description

We resolved an issue where the compensation field could not be updated using the PATCH /jobs/{jobId} endpoint.
The bug occurred when users attempted to nullify or delete the compensation value.

Impact

The change is backward compatible, and the fix restores the documented functionality.

References

• Update a job endpoint

Description

We have introduced enhanced validation measures to prevent the creation of duplicate records during candidate updates.
Validation is not passed when an attempt is made to update a candidate's email address or last name to one already
associated with another candidate. In our system, the combination of email and last name must be unique, and it is not
possible to have two candidates with the same email address and last name.

Impact

This change affects the PATCH /candidates/id endpoint (operationId: candidates.update) in the Candidates API. If users try to update a candidate's e-mail
or last name to one that another candidate already owns, they will receive a 409 Conflict status code with
the code CANDIDATE_DATA_CONFLICT.

References

• Update candidate details endpoint

Description

We have removed UUID validation for the id property in the PUT /candidates/{id}/jobs/{jobId}/properties endpoint
(operationId: candidates.properties.values.batchUpdateForJob). This change is intended to maintain consistency with other parameters
that do not have this format enforced. The valid format for the id remains unchanged and will remain as UUID.

Impact

There shouldn’t be any significant impact as there were no server-side validation of this format.
If user doesn’t provide UUID, he will receive status 404 NOT FOUND with code PROPERTY_NOT_FOUND as usual.
The only potential impacts are:

• relaxed validation in the Swagger/UI of the Developer portal
• if the user manually reads and interprets OpenAPI Specification for any reason.

References

• Update property endpoint
• OpenAPI specification

Description

We have added support for the latitude and longitude properties for the location object.

Impact

Job and Job ad can be created and updated with coordinates: latitude and longitude provided in the location property.
This change is backward compatible. The latitude and longitude properties are optional.
If not provided, the Job or Job ad location will be saved/updated without the coordinates.

References

• Jobs API

Description

Sandbox Public API [BETA] endpoints are for creating customer integrations using new sandboxes.

There is a concept of configuration id introduced. This is an additional identifier linking related entities in production company and sandbox(es). If integration hardcodes the configuration id of referenced object instead of entity id the actual entity id for the production/sandbox company (associated with the credentials) could be retrieved from the entity mapping. This allows for keeping the integration code intact while running it against production or sandboxes.

These are the new sandboxes endpoints:

• getting list of available entity names [BETA]: /configuration/entity-mapping/entity-names
• retrieve entity mappings by configuration id [BETA]: /configuration/entity-mapping/entity-name/{entityName}/by-configuration-id
• retrieve entity mappings by entity id [BETA]: /configuration/entity-mapping/entity-name/{entityName}/by-entity-id

Notes:

• please be aware that these endpoints are [BETA] and can be changed or removed without prior warning.
• department entity mappings currently available only using dedicated DEPARTMENT entity name. Not available as backing it JOB_PROPERTY.

Impact

There is no impact of this change on the users. New endpoints don't change any existing functionality but introduce a new one.

Also these endpoints are [BETA] and can be changed or removed without prior warning.

References

• Getting list of available entity names
• Getting entity mappings by configuration id
• Getting entity mappings by entity id