Implement, Test and Deploy APIs
Fetching an access token
You must use an access token in order to access protected APIs.
For more information about the token API, see Obtain an access token via an OAuth client credentials grant. This is a standard OAuth2.0 Client Credentials token API.
The following is an example of a cURL request for the token API. The content of the basic authentication header must be "yourClientID:yourClientSecret" encoded in Base64.
curl --location 'https://gwg.cloud.utmost.co/api/gwg/supplier/oauth/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic **************' \
--data-urlencode 'grant_type=client_credentials'| If you are testing in Postman, refer to Authentication Instructions for Postman. |
Calling an authenticated API
All API calls are secured using Bearer Authentication. The client must fetch a token from the token API and send it in the Authorization header when making requests to protected resources:
Authorization: Bearer <token>
If the token is missing, invalid, or expired, the API in question will respond with a 401 error code (unauthorized).
Fetch Job Postings
To interact with the job postings API, you must use a valid access token. For more information, see Security and authentication.
Listing all of your job postings
Use the List Postings API to list all job postings available from your connected Beeline clients in one API call. To improve response times, this API returns a limited set of job posting information.
Fetching the full details of a job posting
To fetch full job posting details, use the job posting details API. When you’ve identified a new job posting, or when you want to review an existing posting, use the Job Posting Details API to get the full set of fields for one particular posting, including rates and client-specific custom fields.
Receiving a notification for new postings
To react to new postings faster, suppliers might like to receive alerts when a job posting is released. Webhook subscriptions are available to support this.
Use the Webhook Management APIs to specify an API on your system that Supplier Network can call when a new posting is released from one of your clients. This way, you can use that API to drive further internal processes in your ATS.
Ensure that the webhook API on your system matches the format provided in the Webhook Examples section of the API documentation.
Supplier Network will cryptographically sign all notifications sent to your API using the HMAC secret you provide when setting up the webhook subscription. To prevent unauthorized parties from calling your API, it is critical that you validate that this signature is correct on all the requests you receive.
Submit a Candidate
When you identify a job posting you are interested in, use the API to submit candidates to that posting.
To interact with the candidate APIs, you must use a valid access token. For more information, see Security and authentication.
Selecting a worker from your talent pool
Before submitting a candidate, create or select the worker profile you want to use for the submission. The worker profile entity contains information relating to the individual that doesn’t relate specifically to this job posting, such as personal information and contact details.
Use the Worker APIs to manage your workers.
Preparing the submission
When you’ve identified a posting and a worker, use the Create Candidate API to create a candidate entity. This candidate will have a CREATED status, which means it can still be edited before submitting it to the client.
Client-specific custom fields
Each client will have different configuration and required fields as requirements for submitting a candidate. Use the Candidate Metadata API to fetch information about the custom fields that are available for this particular posting, and whether they are required or not.
Submitting the candidate
When your submission is ready, use the Submit Candidate API to submit your candidate. The candidate status will change to SUBMITTING, and the candidate submission will be sent to the client VMS.
Next, the client VMS will process the candidate submission. If this is successful, the status will change to SUBMITTED, and the candidate will be available in the client VMS for the selection process to begin. If there is an issue processing the candidate, the status will change to SUBMISSION_FAILED and a detailed error message will be available via the submissionErrorMessage field.
Future enhancements
Monitoring candidate statuses post-submission, including webhook notifications like those provided for job postings are on our roadmap. Please take a moment to view our product roadmap and idea portal and vote for features that are most important to you. We value your thoughts and experience and are committed to continuously improving our offerings to better serve your needs.