API Business Rules

The following business rules govern use of the Job Import API; for examples, refer to Sample XML:

  1. File Processing. When a successful call is executed, the success XML response indicates that the data was submitted to the zone for processing. Because additional data transformation and rules are applied beyond the initial job creation, the success response does not indicate that all of the job actions were executed as expected. Whenever a call is successfully processed, the SmashFly system generates and distributes an email notification (with the subject, "List of jobs auto-imported into SmashFly from the career site for [Customer Name].” This email includes a summary of the actions taken. Note that the job will actually be sent to or removed from boards based on the job board integration method, so changes may not appear immediately on external job boards.
  2. File Type. The post “contentType” should be set to “text/xml."
  3. File Structure. The XML call must be located fully within a parent node called <Jobs>. Each individual job should be within a parent node called <Job>.
  4. Multiple Jobs - IMPORTANT. Multiple jobs can (and should, where applicable) be submitted in each call, but do not use the API for frequent “full feeds” of job data. The API is intended to be used for incremental “delta” data, sent either in real time or at scheduled intervals from a client’s job source system (for example, the Applicant Tracking System).
  5. Job Action is Required. You must include the <Action> node to indicate what action should be taken with the data provided. The possible values are "Add," "Update," or "Delete."
  6. Node Naming. Any node in the XML can be named as desired. You must work with SmashFly to map each node in your XML to the corresponding standard and or custom fields into which the data should feed.
  7. Select Fields. When passing data to fields where a value must be selected (“select” fields), the CODE value for each field value must be supplied. For information about the codes for standard fields, refer to Lookup Values; for custom fields, work with your SmashFly Technical Services Consultant.
  8. Job Location. Job Primary Location data must be passed in separate nodes for City, State/Province, and Country. Location data should typically match valid locations and should use the ISO 2-character Country and State/Province codes (where appropriate).
  9. ZIP Codes. Though not required, SmashFly recommends pushing ZIP/postal code information for each job through the API. If ZIP code is not passed, SmashFly will attempt to look up a ZIP/postal code for the location provided. If no ZIP/postal codes exist for the provided location combination, the ZIP/postal code field will be left blank; this may result in failures when Intellipost is used to push jobs to boards where ZIP/postal codes are required.
  10. Invalid Locations. If invalid city and or state names are to be provided (such as “Statewide” or “Nationwide”), ensure that City/State validation is disabled in the customer zone’s Admin Settings. Confirm with your SmashFly Customer Success Manager or Technical Services Consultant that the validation setting has been disabled.