Skip to main content

Problem solving examples and FAQs


  • Are there any webhooks over the Customer API?

    Yes. We have recently introduced the Webhook API.

  • Can I use dynamic redirect uri (dynamic routing for my users)?

    No. You should use the pre-registered one. Note that it is a case sensitive string.

  • Can I use wildcard redirect uris?

    No. Wildcard redirect_uri is a violation of the OAuth 2.0 spec and it poses a security risk. 

  • How can I distinguish multiple users/customers (multitenant) over my (single) environment?

    • You can attach state parameter in your requests. More details here
    • You can check the user by GET /users/me.
  • What error you can get if your TLS version is too old?

    Authentication failed because the remote party has closed the transport stream.

  • What resources my application has access to?

    With access_scopes you ask the user what endpoints you’d like to make a call to (to be able to make calls to). On the other hand, depending on which user grants you access, you’ll get his access scope in SmartRecruiters and your application runs on the access scope of this user (is able to get the data). See System Roles.

    Example (bad scenario): your application requests full access and SR Standard user allows it. You then have access to all assets (you are able to call all the requested endpoints) but you’ll only be able to get data that this Standard (limited) user has access to. 

  • What this error means: {"message":"No access to feature: Customer API"}

    A company from which a user authorizes the application does not have access to API. Ask Partners Support for subscription and provide the email address you used to authorize this app in SmartRecruiters.

  • What TLS does SmartRecruiters support?

    TLS 1.2 only.

  • When I do the POST call to with grant_type authorization_code, I receive http status code 200 OK and as the response body an empty json object. Why?

    SmartRecruiters only accept a form body, not a JSON body.

    Example request body format:

    curl -X POST \ \

      -H 'Content-Type: application/x-www-form-urlencoded' \

      -H 'cache-control: no-cache' \

      -d '{

        "grant_type": "authorization_code",

        "code": "zzzz",

        "client_id": "abc",

        "client_secret": "xxxx"


  • When I’m trying to exchange the code with an access token, Chrome sends me the error: No 'Access-Control-Allow-Origin' header is present on the requested resource. Why is that happening?

    You’re receiving that error because Chrome (as well as other modern browsers) has a same-origin policy restriction that prevents scripts running in the browser from accessing resources in other domain - at the same time though our authorization server does not implement the CORS headers as it may reduce the security of data flow here.

    At this step (4. Your App requests an access_token) your server should redirect the browser to our /identity/OAuth/token endpoint and manage the tokens exchange on the backend exclusively rather than make an AJAX/XHR request.

    Briefly speaking, in the Authorization Code Grant flow the requests should be made from your server to our server and there’s no need for CORS. Note that the only requests made in the user’s browser are the redirects, which aren’t affected by CORS.