(This full guide is currently no longer the current one - see individual sections of the AWM guide)
 

 

Design Considerations

1.1    Optimizing application completion

The first gate on the way to successfully filling a job posting is the acquisition of candidates. Yet, career sites often find that a significant volume of job applications that are started fail to be completed. Unsatisfactory apply conversion results may be attributed to many factors. Quite often, it is simply due to to challenges in the applicant user experience, such as a lengthy or complex applications, or perhaps trying to complete a form from a mobile device. The lengthier an application, the greater the likelihood that a prospective applicant will fail to see it through to completion. Apply with Monster helps solve these issues by letting job seekers easily utilize their Monster resumes to simplify the apply process.

Enabling the Apply with Monster plug-in is easy; only a few configuration parameters are necessary to begin collecting applicant information via Monster. How Apply with Monster is integrated into a workflow can play a major factor in defining the resulting overall apply success rate. Consider for example, if the minimal set of information required to accept a candidate into your system could be the data obtained via Apply with Monster. This degree of optimization would likely return the highest conversion rate and yield possible.

This degree of streamlining may not be suitable in every case as specific business requirements will vary, but it should be considered as a design goal when developing a solution to achieve optimal results for your business.
 

1.2    Leveraging your integration for jobs posted to Monster

The benefits of implementing an Apply with Monster integration are not limited to jobs at your career sites. Jobs that are posted to Monster can be configured to deliver applicant information in the same manner as for jobs at your career site. The benefits are the same, but multiplied by the power and reach of the Monster brand as a premier job search destination.

AwM doc design considerations

 

1.3    Interaction sequence

Below illustrates the interaction sequence between a job seeker, an integrated client system, and Monster when Apply with Monster is placed on a career site job. Some steps, such as callbacks, are optional and would only occur if enabled within your configuration.

image1

 

1.4    Registering for API keys

The Apply with Monster plugin requires an API key to execute. The API key also authorizes domains to receive applicant information. Therefore, all unique identifying domains that will communicate with Monster for applicant information delivery must be registered. A registered domain authorizes all of its subdomains to utilize Apply with Monster, e.g., registering myats.com would also enable customer1.myats.com, customer2.myats.com, etc. Your architecture and how you manage your customers may dictate how you choose to map domain to API keys for security and ease of operations.

Contact Monster to register your domains and obtain your API keys. Upon registration, Monster will also provide a shared secret value with each API key. Shared secrets are used in different ways depending on the delivery method utilized.

Take Note!

A shared secret value is like a password – use appropriate practices to ensure confidentiality. Never make a shared secret value publicly accessible.

 

Implementing your integration

Enabling Apply with Monster is easy. The behavior of the plugin and how it interacts with your site is controlled via a set of configuration parameters which fall into these basic categories:

  • Basic attributes of the job, namely the job title, company name, and job location. These are echoed in the Apply with Monster pages to present a consistent user experience.
  • How the application data is to be communicated, including the delivery method, data format, and additional configuration parameters specific to the delivery method.
  • Information and event triggers passed through and received from Apply with Monster to facilitate a well-integrated and seamless user experience.
 

2.1    Configuration parameters

Parameter Conditions Data Type Description
data-api-key Required String API key
data-companyname Required, max 255 chars String Name of the hiring company
data-jobtitle Required, max 255 chars String Title of the job
data-joblocation Required, max 20 chars String Postal code of the location of the job.  In locales where a postal code is not used (e.g., IE), the actual name of the location is used here, (e.g., “Dublin”).
data-jobrefcode Optional, max 50 chars String Reference code to identify this job.  Not consumed by Apply with Monster; if specified, the job ref code is simply returned with the applicant data record.   Useful for correlating received applicant information with a job.
data-accountkey Optional, 40 chars String SHA1 hash of the Monster employer account username
data-deliverymethod Required; values “POST”, “EMAIL”, “REQUEST” String Method for obtaining applicant information
data-deliveryformat Optional; values “JSON” or “XML”; defaults to “JSON” String Data document format 
data-posturl Required if data-deliverymethod = “POST”; otherwise ignored String REST service where applicant information is to be POSTed
data-emailaddress Required if data-deliverymethod = “EMAIL”; otherwise ignored String Email destination where applicant information is to be sent
data-onclick Optional String JavaScript function to be called when the user has clicked on the Apply with Monster button. See section JavaScript callbacks for more info.
data-onsuccess Required if data-deliverymethod = “REQUEST”; otherwise optional String JavaScript function to be called when the user has successfully submitted their Monster information for the job. See section JavaScript callbacks for more info.
data-oncontinue Optional String JavaScript function to be called when the user closes the Apply with Monster modal. See section JavaScript callbacks for more info.
data-vendorfield Optional String General purpose field for vendor data.  Not consumed by Apply with Monster; if specified, the vendor field is simply returned with the applicant data record.   Useful for specifying metadata.
data-isConfirmationDisabled Optional; values "0" (default) or "1" String If set, disables the display of a submission acknowledgement to the seeker. Sometimes desirable if there are additional mandatory interview questions.
src Required string Apply with Monster application URL.  URL will vary depending on desired localization.  See section Localizing the Apply with Monster user experience.
An example of invoking Apply with Monster within a web page

The script below must be present on every page where Apply With Monster is to be presented.

<div id="awm_widget"></div>
…
<script id="awm" type="text/javascript"
       data-api-key="EAAQwQeZBhB3MyyOhCNzymbYoA--"
       data-companyname="519 Software, LLC"
       data-jobtitle="Senior Software Engineer"
       data-joblocation="02142"   
       data-jobrefcode="abc"
       data-deliverymethod="POST"
       data-deliveryformat="JSON"                
       data-posturl=<your_REST_service_URL_here>
       data-onclick=<your_js_callback_function_here>
       data-onsuccess=<your_js_callback_function_here>
       data-oncontinue=<your_js_callback_function_here>
       data-vendorfield=<your_metadata_here>
       src="//login.monster.com/awm/en_US/awm.js">
</script>


When properly configured, the Apply with Monster button looks like this:

image2

Sometimes, it is desirable to display multiple Apply with Monster buttons with a job description, if for example, the job description is lengthy. Up to three Apply with Monster buttons can be displayed with the additional scripting:
<div id="awm_widget_2"></div>
<div id="awm_widget_3"></div>

Take Note!

The Apply with Monster button will only be displayed if a valid configuration is specified, e.g, if data-deliverymethod is "POST" but data-posturl is not provided, the Apply with Monster button will not display.

Take Note!

Apply with Monster utilizes the jQuery JavaScript library and dynamically loads jQuery if version 1.7 or greater is not detected. jQuery.noConflict enabled to protect clients' existing scripts.

 

2.2    Customizing the visual appearance

2.2.1 Localizing the Language

For the best user experience, the right localized content must be presented to the job seeker.  The language localization of Apply with Monster text copy is configured by specifying the desired locale as part of the src configuration parameter. The src value takes the format:

//login.monster.com/awm/{locale}/awm.js 

The {locale} specification is a concatenation of ISO language and country codes, a convention used at many sites. For example, to display content in US English, the src value would be:

//login.monster.com/awm/en_US/awm.js 

The following localizations are currently supported:

 

Country Language Locale
Australia English en_AU
Australia German de_AT
Belgium Dutch nl_BE
English en_BE
French fr_BE
Canada English en_CA
French fr_CA
Czech Republic Czech fr_FR
Denmark Danish da_DK
Finland Finnish fi_FI
France French fr_FR
Germany German de_DE
Hungary Hungarian hu_HU
Ireland English en_IE
Italy Italian it_IT
Country Language Locale
Luxembourg English en_LU
French fr_LU
German de_LU
Netherlands Dutch nl_NL
Norway Norweigan no_NO
Poland Polish pl_PL
Russia Russian ru_RU
Slovak Republic Slovak sk_SK
Spain Spanish es_ES
Sweden Swedish sv_SE
Switzerland French fr_CH
German de_CH
United Kingdom English en_GB
United States English en_US
 

Take Note!

For pre-existing integrations, a src value of "//login.monster.com/Awm/javascript/awm.js" is also supported and equivalent to "//login.monster.com/awm/en_US/awm.js".


2.2.2    Choosing an alternative button presentation

By default, the Apply with Monster button appears as in the previous example, localized accordingly. Alternative button styles are also available, specified by an optional parameter on the src value, e.g.,
//login.monster.com/awm/en_US/awm.js?sv=2 

sv parameter value style
{not specified} or 0 standard button
1 smaller button
2 standard size, complementary palette
3 smaller size, complementary palette
 

2.3    Correlating apply activity to jobs also posted on Monster

Increasingly, employers are demanding greater insight into the sourcing of applicants. For Monster customers, all Apply with Monster apply activity at the customer's career site can be tracked by the Monster employer account to get a total accounting of performance for jobs.  This is inclusive of jobs cross-posted to Monster, as well as jobs not cross-posted to Monster but receiving the Apply with Monster benefit.  To enable tracking, the Monster account username is identified within the configuration settings. The optional data-accountkey parameter is used to specify the Monster employer account username by its SHA1 hash value. For example, a user account named "myaccount" is represented as:

   data-accountkey="ad340c3184c3c4e3e84e5dce43b0cd27096e2085"
   
When data-accountkey is specified, data-jobrefcode is referenced to determine if this job is also posted on Monster for attribution purposes.

Take Note!

If a job was also posted to Monster, data-jobrefcode should match the jobRefCode value specified during the Real Time Posting action.

 

2.4    JavaScript callbacks

The originating page from where the Apply with Monster plugin resides can react to specific Apply with Monster event conditions by utilizing JavaScript callbacks. Optional configuration parameters define JavaScript callback functions mapped to those events. Utilizing the JavaScript callbacks can be useful for gaining awareness for a range of purposes such as tracking click activity and continuing on to additional steps.

Configuration Parameter Triggered when the user… Event data example
data-onclick clicks on the Apply with Monster button {"event":"click", "job":{"companyName":"ABC Consulting", "jobTitle":" Analyst", "jobLocation":"01754", "jobRefCode":"jr123", "vendorField":"mymetadata"}}
data-oncontinue closes the Apply with Monster modal {"apply":{"success":true}, "event":"continue", "job":{"companyName":" ABC Consulting", "jobTitle":"Analyst", "jobLocation":"01754", "jobRefCode":"jr123", "vendorField":"mymetadata"}}
data-onsuccess ("POST", "EMAIL" delivery methods) presses "SUBMIT NOW" {"event":"success", "job":{"companyName":"ABC Consulting", "jobTitle":"Analyst", "jobLocation":"01754", "jobRefCode":"jr123", "vendorField":"mymetadata"}}
data-onsuccess ("REQUEST"delivery method) presses "SUBMIT NOW" {"req":{"requestUrl":"https%3a%2f%2flogin.monster.com%2fAwm%2fApplyRecord%3fapikey%3dEAAQ33Nb18vQ34xbnqYiR2KayESo9mwTmdI9MsrWNfAK9q4-%26adt%3dEAAQbLTWk.pUfmRb5dAUyfsnWxKWADzVmXvYNzAMK67_8gBEIXiNG4O.XOJgih1ryKveZXvNxWDzLhrqGwN_Jt1vmdlPvsfyP_cVyOHkHLSo9capgx67OSoaolAwAxlLLResYxOcsNH8BeJoG5HjnjOPEKsqVwhDuar2gxpoCLoucGG4TvkVGmscV5k_rxOzm6_3qQND5i6qK_WGqj3Wl1SBBi5pkTUucxlzDUFoM3LYq.VjUQRQUa.UuOrohzoZS6k4A1zMdtMgv98rS9evhMWl1lasze6.Kx6QtS8hv5wfSOHSD7AeKigXYjq383vPNXW_BwwIC4dy_J75zgjgNiBEuFw6IeDcULItYsCyUZQMiPuq4PmAxCLs6TOiziW8cBP_X.Q0HRDx7rRSaDIX4wKzANT15yxFXNbMzJ.PDtS2QE.Gqr2XxvXLjKkuzoXS6MIkSUAANDvMzmnmDW6RlfQxgqJczTaHMhExO48rBQQWM2UCnTsjLjOhPCO2mCcn0c1F5Vrvbli5TW.fP1aB5DnR_7omWe0eenPSKO9.dagy1k0knNJKpNVbLYrwiXdyxW8279IKIrwdqCZX8pnw4K4ZxT1WUxkLK145dkNJ3.UVf30f8wkHrz5pLGwamrE4nlWXg_iAGcmJnubqCgYI5pl8Poa576v6GJq4FD4goGSCB9LKFX_7cq6fMHvhqsM1T_DbxvOeWOwUfzmCHs2.6pbRSK6idqUtq8ygffLlDIhA9c0-"}, "event":"success", "job":{"companyName":"RequestTest", "jobTitle":"Tester", "jobLocation":"02142", "jobRefCode":"Sean123"}}
The callbacks each return an object that includes event name and job configuration attributes. In addition, the continue event also includes the success state which is only true if the modal was closed after a user presses "SUBMIT NOW".

When data-deliverymethod is "REQUEST", data-onsuccess is also required to be specified. Details of this usage are provided in Section 2.4.3, Obtaining applicant information via HTTP GET.
 

2.5    Obtaining an applicant's information

There are three different methods for obtaining an applicant's submitted information:

data-deliverymethod Description
EMAIL An email is delivered to the specified email address.
POST Applicant information is POSTed to a specified REST service.
REQUEST On notification of applicant submission, the client system makes a web service request to obtain the applicant information.


Take Note!

Unicode (UTF-8) character encoding is used for all content.

Take Note!

Monster provides a resume in its original format as it was made available to our site. If a resume was created interactively on Monster, the resume is provided as consistently formatted HTML. If an applicant originally uploaded a resume to Monster (e.g., as a PDF), it is delivered in the original document format.



2.5.1    Receiving applicant information via email

Email is the simplest way to start receiving applicant information. If data-deliverymethod is set to "EMAIL", applicant information is delivered to the email address named in data-emailaddress. The email address named in data-emailaddress can be specified in clear ASCII format:

data-emailaddress="applicant@myats.com"

or its Base64 equivalent:
data-emailaddress="YXBwbGljYW50QG15YXRzLmNvbQ=="

Take Note!

Optional Base64 encoding serves as a handy lightweight technique to help avoid potential harvesting by email scrapers. It is not an encryption scheme, nor a foolproof obfuscation scheme for a determined harvester.



With email delivery method, the applicant information email is provided in HTML format with the resume and cover letter provided as attachments. For ease of optional post-processing, the job and applicant information contained within the email body is also provided as an attachment, formatted as specified by data-deliveryformat. If data-deliveryformat is not specified, JSON format is defaulted.

Take Note!

The domain of a target data-emailaddress must be registered for use with the referenced data-api-key for the Apply with Monster button to display. As an alternative to registering each new customer's domain(s), it may be more efficient to configure data-emailaddress to <newcompanyname@yourregistereddomain> and forward the email to the intended target email address.



Sample applicant email when email delivery method is used

Apply with monster notification



2.5.2    Receiving applicant information via HTTP POST

HTTP POST to a REST webservice is a common method for accepting applicant information for subsequent processing. If the data-deliverymethod is set to "POST", the applicant information is delivered to your REST webservice as specified by data-posturl upon the job seeker's submission. The REST service must be able to accept the content as defined by data-deliveryformat.

The POST URL specified by data-posturl can be specified in clear ASCII format:

data-posturl="http://www.myats.com/awm/apply"

or its Base64 equivalent:

data-posturl="aHR0cDovL3d3dy5teWF0cy5jb20vYXdtL2FwcGx5"

Take Note!

The domain of a target data-posturl must be registered for use with the referenced data-api-key for the Apply with Monster button to display.



Validate the authenticity of POST data

As a best practice, data received via POST from an external source should be validated to ensure its authenticity and integrity. The HTTP POST transaction request header contains two fields that are used to validate the contents of the apply data within the transaction body:

Header Field Description
AwMHash The hashed representation of the serialized apply data using HMAC-SHA1 hashing technique, and the shared secret corresponding to the API key as the hashing key
AwMApiKey API key; this is only needed if there are multiple API keys in use


To validate the transaction, independently hash the serialized apply data in the transaction body using the closely held shared secret. If multiple API keys exist in your environment, AwMApiKey is provided as reference to identify the corresponding shared secret to be used for the local hash calculation. The resulting locally calculated hash value is then compared with AwMHash to verify a match.

Example of validating a hash

…
	// Verify the HMACSHA1 hash of the data
	var apiKey = this.Request.Headers["AwMApiKey"];
	var hashData = this.Request.Headers["AwMHash"];
	var hmacSha1Hash = Convert.FromBase64String(hashData);

	// Get the hash key to use to check the hashed value
	// NOTE: This key needs to be kept private
	byte[] hashKey = Encoding.UTF8.GetBytes(GetHashKey(apiKey));
	using (HMACSHA1 hmac = new HMACSHA1(hashKey))
	{
		byte[] computedHash = hmac.ComputeHash(this.Request.InputStream);
		// Compare the bytes from the hash that was sent vs. the hash that was just generated
		// NOTE: Use the computedHash as your base comparison as that is the trusted value
			for (int i = 0; i < computedHash.Length; i++)
			{
			if (computedHash[i] != hmacSha1Hash[i])
			{
			throw new InvalidDataException("Hash value mis-match when validating data
			sent - Data cannot be trusted");
			}
			}
	}
…


Now, you're ready to continue; proceed to Section 2.6, Processing an applicant's information.



2.5.3    Obtaining applicant information via HTTP GET

Applicant information can also be obtained on request via HTTP GET. This method might be preferable if the applicant information is needed synchronously in advance of ensuing steps. When a data-deliverymethod of "REQUEST" is specified, the JavaScript callback specified by data-onsuccess is also required. For this usage, the success event returns an additional element, req.requestUrl.

The requestUrl field is the target URL-encoded URL for where to make a HTTP GET request to retrieve the applicant's information. To authenticate requestors, when making the HTTP GET request, the shared secret that you obtained with your API key must be appended as an additional parameter, in the format, "&stoken=<yourSharedSecret>" ,e.g.,

Sample HTTP GET request:

https%3a%2f%2flogin.monster.com%2fAwm%2fApplyRecord%3fapikey%3dEAAQ33Nb18vQ34xbnqYiR2KayESo9mwTmdI9MsrWNfAK9q4-%26adt%3dEAAQbLTWk.pUfmRb5dAUyfsnWxKWADzVmXvYNzAMK67_8gBEIXiNG4O.XOJgih1ryKveZXvNxWDzLhrqGwN_ ... v6GJq4FD4goGSCB9LKFX_7cq6fMHvhqsM1T_DbxvOeWOwUfzmCHs2.6pbRSK6idqUtq8ygffLlDIhA9c0-%26stoken%3d12345


This call will return the applicant information in response.

Take Note!

Applicant information is expected to be retrieved shortly after submission notification. After 24 hours, applicant information is no longer retrievable.

 

2.6    Processing an applicant's information

If EMAIL delivery method is utilized, there is no further processing necessary; an applicant's resume and cover letter are provided in their original formats as email attachments.

For the POST and REQUEST delivery methods, the applicant data record in the transaction body must be deserialized to the specified data-deliveryformat. The applicant data record is comprised of the following:

	string FirstName
	string LastName 
	string EmailAddress
	string PhoneNumber
	string CoverLetter 
	string JobRefID
	string VendorField
	string FileExt 
	byte[] FileContents 
Record elements will only appear if there is corresponding data; if, for example, a JobRefID was not specified by the configuration, it will not be supplied in the applicant record. The FileExt field identifies the file extension for the resume document contained in the FileContents byte stream. Possible values are: .doc, .docx, .pdf, .rtf, .txt, and .html. Resume size can be up to 5 MB. Due to some additional data and overhead coming from the serialization / deserialization process, we recommend the following:

• XML format should be set to accept up to 8 MB
• JSON format should be set to accept up to 20 MB

Example of deserializing XML data

…
using System.Xml.Serialization;
…
                ApplyRecord am = new ApplyRecord();
                if (this.Request.ContentType == "text/xml")
                {
                    XmlSerializer xml = new XmlSerializer(typeof(ApplyRecord));
                    am = (ApplyRecord)xml.Deserialize(this.Request.InputStream);
                }


Example of deserializing JSON data

…
using System.Runtime.Serialization.Json;
…
                {
                    DataContractJsonSerializer djs = new DataContractJsonSerializer(typeof(ApplyRecord));
                    am = (ApplyRecord)djs.ReadObject(this.Request.InputStream);
                }



Raw data sample for JSON format with Cover Letter:

{"CoverLetter":"Dear Hiring Manager,\u0009\u000a\u000aI was excited to see your job posting for this job.\u000a\u000aSincerely,\u000aSeeker","EmailAddress":"testseeker@something.com","FileContents":[ 60,0,33,0,45,187,191,78,97,109,101,32,67,111,111,107,105,101,32,77,111,110,115,116,101,114,13,10,65, … … … 191,207,133,206,189,33,13,10,13,10],"FileExt":".docx","FirstName":"Seekerfirstname","JobRefID":"Testjobrefid","LastName":"Seekerlastname","PhoneNumber":"999-999-9999","VendorField":"12345"}


Raw data sample for XML format with Cover Letter:

<?xml version="1.0"?>
<ApplyRecord xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<FirstName>Seekerfirstname</FirstName>
<LastName>Seekerlastname</LastName>
<EmailAddress>testseeker@something.com</EmailAddress>
<PhoneNumber>999-999-9999</PhoneNumber>
<CoverLetter>Dear Hiring Manager,
        
I was excited to see your job posting for this position.    
Sincerely,
Monster Test Seeker</CoverLetter>
<JobRefID> Testjobrefid </JobRefID>  
<FileContents>PAAhAC0ALQBIAFQATQBMAFIAZQBuAGQAZQByAGUAcgAtAC0APgANAAoAAbQBlAE4A
…
…
…
AC8AdAByAD4APAAvAHQAYQBiAGwAZQA+AA==</FileContents>
<FileExt>.pdf</FileExt>
</ApplyRecord>


HTML Sample - here is an example of a resulting html file after deserializing the FileContents field for a resume that was created interactively at the Monster site (e.g., not uploaded as a .doc or .pdf):

<!--HTMLRenderer--> 
<!--ResumeNavigationLinks--> 
<!--ResumeInstructionalText--> 
<!--Referral--> 
<!--ContactInfo-->
<table border="0" cellspacing="0" cellpadding="0" width="650" 
xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:m="http://schemas.monster.com/Monster"
xmlns:ms="urn:schemas-microsoft-com:xslt" />

<!--Title-->
<table border="0" cellspacing="0" cellpadding="0" width="650" xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <tr>
    <td><a name="resume">
      <table cellspacing="0" cellpadding="0" border="0" width="100%" class="sectionHeaderBackground">
        <tr>
          <td width="180" style="height:1px; width:180px;" />
          <td colspan="2" style="height:1px; width:470px;" />
        </tr>
        <tr style="background-color:#e5ecf3;">
          <td height="18" width="180"><span class="boldText">RESUME</span></td>
          <td height="18" class="SmallText" align="left">  </td>
          <td height="18" align="right" class="smallBoldText" />
        </tr>
      </table>
      </a></td>
  </tr>
  <tr>
    <td height="15" />
  </tr>
  <tr>
    <td colspan="2" class="SmallText" style="
 padding-left:7px;

    "><table border="0" cellspacing="0" cellpadding="0" width="100%">
        <tr>
          <td align="left"><span class="boldText">Resume Headline: </span>
            <ResumeTitle>af_built</ResumeTitle></td>
          <td align="right"><span class="boldText">Resume Value: </span>
            <ResumeValue>ncr3894r3kmhfazs</ResumeValue>
               </td>
        </tr>
      </table>
        </td>
  </tr>
  <tr>
    <td height="15" style="border-top:1px solid #e5ecf3;" />
  </tr>
</table>
<!--Summary--> 
<!--Experience-->
<table border="0" cellspacing="0" cellpadding="0" width="650" xmlns:fo="http://www.w3.org/1999/XSL/Format">
  <tr>
    <td class="boldText" valign="top" style="padding-left:7px;" width="180">EXPERIENCE:</td>
    <td class="smallText" valign="top" width="150">6/2008 - Present</td>
    <td class="smallText" valign="top" width="150"><Company>Monster</Company></td>
    <td class="smallText" valign="top" width="150"><Location /></td>
  </tr>
  <tr>
    <td class="boldText" valign="top" style="padding-left:7px;" width="180"></td>
    <td class="smallText" valign="top" colspan="3" width="450"><b>
      <ExperienceTitle>Support</ExperienceTitle>
      </b></td>
  </tr>
  <tr>
    <td height="15" />
  </tr>
  <tr>
    <td class="boldText" valign="top" style="padding-left:7px;" width="180"></td>
    <td class="smallText" valign="top" colspan="3" width="450" />
  </tr>
  <tr>
    <td height="15" />
  </tr>
</table>
<!--Education--> 
<!--Certification--> 
<!--Skill--> 
<!--Language--> 
<!--Award--> 
<!--CAREER HIGHLIGHT--> 
<!--Interest--> 
<!--Affiliation--> 
<!--Reference--> 
<!--CustomFields--> 

 

2.7    Adapting a Monster job posting to utilize your Apply with Monster integration

Jobs posted to Monster can be configured to leverage your Apply with Monster integration's service for receiving applicant information. Just like for jobs posted at your career site, enabling jobs posted to Monster in this way will boost applicant conversion by further simplifying the apply process.

To enable jobs posted to Monster, simply specify a subset of your Apply with Monster configuration parameters to your Real Time Posting (RTP) implementation

 

Testing Your Integration

Here are some suggestions for testing your Apply with Monster integration:
  1. Create a web page on your site with the Apply with Monster plugin enabled with the TEST data-api-key in place in the script. Verify that the Apply with Monster button appears as desired. The button will only render if a valid set of configuration settings are defined.
  2. Create a new seeker account on Monster's site and create a resume interactively using Monster's Resume Builder.
  3. Click the Apply with Monster button, and sign into your test job seeker account.
  4. Complete Apply with Monster for this test seeker, and close the Apply with Monster modal dialogue.
  5. Verify that your service is able to receive the applicant information according to your specified delivery method. If using:
    1. EMAIL – verify that the email is received
    2. POST – verify that the hash can be verified and the applicant information is processed
    3. REQUEST – verify that the applicant information is processed
  6. Repeat the Apply with Monster flow with various combinations of different resume document types (e.g., .doc, .docx, .pdf) and including and excluding a cover letter to simulate a wide range of applicant characteristics that you will encounter. For ease of testing, we suggest creating multiple test seeker accounts, each with a different resume document type.


Take Note!

Different API keys are issued for TESTING and Production. Be sure to use the proper API key(s) and corresponding shared secret value(s) issued for the intended purpose.