Skip to main content

Creating and managing postings

A request is always submitted using an HTTP POST to the address: https://ws.idibu.com/clients/api/REMOTE/V3/[client-hash]. Refer to the Authentication article for more information about the [client-hash].

The XML data should be sent in a variable called: xml_text and must be URL-encoded.

Submitting and encoding guidelines​

  • Make sure you post the data as application/x-www-form-urlencoded type.
  • Please use UTF-8 encoding and always set the appropriate configuration element (<utf8_enable>yes</utf8_enable>) within the Config section.
  • For the description field of the Job section, please use HTML formatting and, even if you don't support it, please always send <br /> tags instead of plain-text newlines (or control the paragraphs using <p> tags).
  • idibu only supports the following HTML tags:
    • b
    • strong
    • i
    • em
    • u
    • ul
    • ol
    • li
    • br
    • p
    • hr
    • div
    • span
    • pre
    • code
  • However, even though idibu will pass whatever is provided over to the Portals, it is strongly suggested to only use the most basic formatting (limited to the tags above in bold), as many websites won't accept more detailed formatting - potentially resulting in your clients' postings being either misformatted or rejected.
  • For any free-text fields, use CDATA.

Methods​

Refer to the articles below for more details and examples on each of the methods that can be triggered using the Job Posting API:

Direct Posting vs. PCP​

Direct Posting is a concept of full, "360" API integration that requires the Partner to fully manage the posting process and the UI, allowing more control and flexibility. If you follow the Direct Posting workflow, you are therefore not using the UPP or PCP; in fact, generating a Post Completion Page in the API response will most likely constitute an error for you.

A successful Direct Posting is indicated by the job status="added" in the API posting response.

Direct Posting requires:

PCP, on the other hand, requires:

  • a functional Job section only;
  • a more involved Config section if you wish to take more control of the UI, the redirections, and the overall posting process.

PCP allows to completely omit the Posts section (although it can still be utilized to pre-fill the Extra Fields in the PCP UI).

A Post Completion Page will always be generated if:

  • In the Config section:
    • lockboards is set to no or yes_pcp.
  • In the Posts section:
    • at least one required Extra Field is missing (or contains wrong data);
    • the provided board id values are wrong, or the account is not subscribed to any of them, resulting in idibu finding no valid Portals to post to;
    • the duration days value for at least one of the board items is incorrect or missing;
    • no board elements are provided at all.

Managing the postings​

The primary service for viewing all Jobs and their connected Posts (created with the above methods) is the Job Management webservice. It should be used to query Jobs' data, track Posts' statuses, and display the list of Jobs and their Posts to users of your software.

Non-dynamic integrations​

Not all idibu Portal integrations rely on dynamic API connection; some utilize batch upload methods through FTP, email, or locally-stored files. For the majority of such 'non-dynamic' connection types, idibu's Post's <status> will only report on whether the job file transfer was successful or not - idibu will have no further visibility of whether and when the specific Portal actually processes and publishes the advert (which might be subject to even up to 24 hour delay); and no posting <link> will be provided by the Job's detailed view method.

The connection type is indicated by the <dynamic> element of the Portal Management webservice.