Skip to content

Common Tasks

Jump to bottom
Andres Freyria edited this page Aug 15, 2017 · 12 revisions

The following tasks are written from the perspective of a user driving the HAL Browser Client manually. When building a client, one must decide which features are implemented and how to best translate these steps programmatically. As such, this is not a comprehensive list; it is intended as a way to become familiar with the API.

Sending an application

To send an application to a candidate, you must first navigate to the desired wepow:interview. From there, the wepow:applications relation will be available. To create (and send) a new one, POST to it with the following information:

candidate : { email : 'candidate@email.com', first_name : 'John', last_name : 'Doe' }

This will create a wepow:application for the wepow:candidate that is associated with the given email. If the wepow:candidate does not already exist, it will be created with the provided name information.

While the name information is optional, we strongly encourage sending it, as it makes searching for candidates easier and more convenient.

Viewing a candidate's application

In order to see a candidate's application, you must first navigate to the appropriate application. There are several ways to go about this:

Once you are at the desired wepow:application, simply follow the relation wepow:application:response, which can be opened as an iframe or as a stand-alone page.

Receiving application status updates

Once an application is created, you may wish to trigger certain actions depending on the status changes it goes through. We provide a notification system that allows you to manage callbacks for these events through the wepow:notifications relation, available at the root of the API. This relation contains all the registered wepow:notification callbacks, and can also be sent a POST request to create a new one.

There are a few caveats that are important to consider:

  • Notifications are sent within 5 minutes of the events occurring, so there is a brief delay involved.
  • If the callback URL returns a failure code (4xx or 5xx HTTP code), we will re-attempt delivery at exponentially increasing times. This is to ensure that temporary availability issues don't result in missing notifications.
  • Due to the above, it is possible to receive a notification that is no longer up to date. A simple solution is to keep a timestamp of the last accepted date_updated property of the resource, and silently ignore anything with a value lesser than the timestamp.
Clone this wiki locally