X

Actions

Home > Application Reference > Bullhorn

Jump to a Section

Overview

Authorizing an Account

The first time you add a Bullhorn card to a Flow, you need to set up a configuration for that Channel. Setting up a configuration will allow you to connect the Designer to your Bullhorn account, save the data, and reuse that configuration next time you build a Flow with this card. That way, you don’t have to sign in every time you want to build a Flow with this Channel. After you’ve set up one configuration, you can choose to use that configuration again, or set up a new one.

You can set up and save multiple configurations and share them with your teammates. Here’s how to set up a new configuration in Bullhorn:

  1. Add the Bullhorn card you would like to use to your Flow. If you already have configurations set up, you will have to select Add Account to create a new configuration. If you don’t have any configurations set up, you will automatically be taken to the next step.
  2. Name your configuration. Choose something unique, since you may need to be able to tell multiple configurations apart in the future.
  3. Please enter your username and password for Bullhorn.
  4. Click Authorize.

    Actions

    • Custom API Action

      This action allows you to make a custom, authenticated HTTP call to the Bullhorn API.

      NOTE: This is not like any of the other Bullhron cards; this card shows some of what goes on behind the scenes on other cards. If you have no experience working with API calls this may be a challenge, however this card is highly customizable. Good luck, and it may help if you refer to the Bullhorn REST documentation!

      Options

      • Request Type (dropdown): your available HTTP request methods. There are 5 supported HTTP request methods (sometimes called verbs) in custom API calls:

        • GET: retrieves data from a web server based on your parameters. GET requests a representation of the specified resource, and if successful will receive a 200 OK response message with the requested content. Additional documentation here.

        • POST: sends data to a web server based on your parameters. POST requests include actions like uploading a file. Multiple POST’s may result in a different outcome than a single POST, so you should be cautious about unintentionally sending multiple POST’s. If a POST is successful, you will receive a 200 OK response message. Additional documentation here.

        • PUT: sends data to a location in the web server based on your parameters. PUT requests include actions like uploading a file. The difference between a PUT and POST is that PUT is idempotent, meaning that the result of a single successful PUT is the same as many identical PUT’s. If a PUT is successful, you will receive a 200 response message (usually 201 or 204). Additional documentation here.

        • PATCH: applies partial modifications to a resource on a web server based on your parameters. PATCH is not idempotent, meaning that the result of multiple PATCH’s could have unintended consequences. If a PUT is successful, you will receive a 200 response message (usually 204). Additional documentation here.

        • DELETE: deletes the specified resource from the web server based on your parameters (if the resource exists). If a DELETE is successful, you will receive a 200 OK response message. Additional documentation here.

      Input Data

      • Relative URL (text): the address on the web server you are attempting to interact with. Relative URL means that you don’t have to explicitly specify the protocol at the beginning of the URL (such as “http://“). This suggests to the web server that the interaction is occurring on the server (in this instance).

        Example: search/Candidate

      • Query (object or text): JSON object that determines the action taken at the URL.

        Example: {"isDeleted":"0"}

      • Headers (object): JSON that determines the content type of the request. This will usually be a replica of the example below.

        Example: {"Content-type":"application/json"}

      Output Data

      • Status Code (Number): the success or failure of your HTTP request. Here is a list of all status codes.

      • Headers (object): a more detailed context for the response/status code that doesn’t relate to the output body. Not all headers that appear in a response header are response headers, meaning that some are unlikely to be useful to you.

      The response headers are dependent on the HTTP request you choose in options.

      • Body (object): depending on the HTTP request you chose in Options, you may receive some data back. That data, such as the data from a GET request, will be contained in this Body object.