Skip to main content

Common workflows

This document outlines basic logic and suggested order of actions that your software should follow when using idibu's Job Posting API and Webservices to ensure the best possible efficiency.

1. Configuring Client accounts​

  1. Create a new Client account - if possible, please avoid creating idibu accounts automatically for every client of your software; instead, initiate the creation only for customers who actually wish to enable multiposting and candidate tracking powered by idibu in your system.
  2. Enable appropriate products on the created account - contact your idibu representative to find out the list of products that should be assigned to each of your Client accounts.
  3. Assign posting credits to the created account - this is applicable only if your Partner account is set to work with idibu's Pay Per Post credits, which should be agreed with your idibu representative.
  4. Enable webhooks on the created account - this way, your system will be notified whenever a Post leaves idibu's Posting Queue and every time an Applicant lands in the idibu system.
  5. Adjust the created account's settings - most commonly, you may want to enable more currencies and customize statuses that can be assigned against Applicants (only applicable if you want to further manage candidates through idibu rather than pushing them straight into your system).

2. Configuring User profiles​

  1. Create Offices and Teams on the Client account - or allow your customers to do that as part of your system's UI. This is only applicable if you wish to use the Office and Team structure to better organize User profiles and their Portal subscriptions.
  2. Create Users on the account - assign them to Teams, if applicable, and store their IDs for later usage.

3. Subscribing to Portals​

  1. Present the list of available Portals - customers should be able to see the Portals they are currently subscribed to (and view and update their subscription, or unsubscribe), as well as search for the ones they are not subscribed to.
  2. Allow to subscribe to a given Portal - some Portals (most importantly, LinkedIn Jobs and LinkedIn Personal Shares) may need some of their fields to be filled in through Oauth, using the LiveAuth API. Different subscription info can be provided for each User, as well as Team and Office, if utilized.

4. Posting adverts​

  1. Retrieve all the required data first - map or automatically fill what you can from your system, and allow customers to enter the rest, displaying all the fields needed for the next step.
  2. Construct the posting XML using all the data from the previous step.
  3. Perform the posting - save the Job ID and tie it to the vacancy object in your system. Proceed to the next step if performing the Direct Posting; or load and display the Post Completion Page in your UI first, so that users can select the Portals, fill in the Extra Fields, and finalize the process.
  4. Receive and process the Post webhooks if needed - the events will inform you when Posts leave the Posting Queue and what their status is.
  5. Manage the Jobs and their Posts - by knowing idibu's Job ID associated with the vacancy in your system, you can display and allow your users to manage all related Posts; or you can utilize this webservice to build a whole advert management interface for all idibu Jobs on the Client account.

5. Processing candidates​

  1. Receive and process the Applicant webhook - the events will inform you whenever a new Applicant arrives and what Client, User, Job, Post, and Portal they are tied to. Save the aptrack_id!
  2. Retrieve the Applicants - following the webhook event, you can obtain all the detailed info about the candidate; the webservice also allows you to list candidates for your users based on the Job, Portal, etc.

Notes on Application URLs​

If you redirect all candidates to your system's / clients' own application pages, you can send their URLs as the Application URL, which can be individual for each Job or even Post. For the majority of Portals, this will omit the native application form and idibu system entirely. In such cases, you are expected to fully manage the candidate processing, bypassing idibu in the process.

However, many Portals do not support Application URLs (indicated by the lack of the app_url dynfield attribute in the Portal's detailed information response), and therefore the only way to gather candidates from them is to utilize idibu's Applicant Management webservice, as per the process outlined above. It is recommended that you implement this flow even if you utilize your own application pages.

Please also refer to the SEEK details page for more information on Application URL support on that Portal.

Please also be aware that if your Application URLs redirect to a website that could be considered a job board, Portals may reject or take down your Jobs.

Ideally, your Application URLs:

  • should only redirect to an application form for the Job in question;
  • may redirect to the Job's page on your Client's dedicated site, as long as it only holds that Client's Jobs;
  • must not redirect to a Job page listed on a website that allows browsing and applying to Jobs of your other Clients.