Job feed technical guide
Updated at August 20th, 2026
Table of Contents
This guide walks through the technical details and requirements for job feeds.
Best practices for implementation
- Allow for at least two weeks of runaway when making a request to your Paradox Admin to have a Job Feed processed or career site scraped. This should be two weeks prior to whatever expectation has been set with the client for setting up a demo environment.
- Please confirm with the client whether they will be providing Staging and Production job feeds or if it will be Production only.
Supported source feed file types
We accept client source feed files in the following formats:
- XML – The easiest and most reliable way for clients to share their jobs from an external ATS with Paradox is through an XML feed, as it is less likely to be affected by software updates on the ATS side.
- JSON
- CSV – CSV is highly not recommended as a file type for job feeds as it is incompatible with our scraping tool and is prone to inconsistencies, along with significant limitations in data formatting and processing.
File transmission methods
Transmission Method |
Notes |
|---|---|
| Public URL / RSS |
This is the most common method clients use to share job data, as it’s just a URL that most ATS’s can generate which holds all of the client’s job requisition data. Anonymized URL example:
RSS Web Feed example: Note: Ensure that the client provides the appropriate credentials if necessary and whitelists our Scrape environment IPs to prevent future delays. |
| sFTP Post |
sFTP, or Secure File Transfer Protocol, means this option is a file-sharing method, and the actual file will need to come in one an XML, JSON, or CSV format.
Technical resources from the client should know about this transfer protocol. They need to configure a process in their system to automatically generate and send us the files. From there, we pick up the files from the folder(s) and process the jobs. Here’s more information on sFTP here: What is Secure File Transfer Protocol?
Notes:
|
| GET or POST Jobs via API |
This method requires us to interact client APIs to retrieve job data, allowing us to pull the source feed file directly from their system.
Note: Ensure the client whitelists our Scrape environment IPs to prevent future delays. Clients will need to share:
|
| Career Site Scrape |
This transmission method should be a last resort. If none of the above options work, then we can pull job data from the client’s career site, though we recommend avoiding this unless absolutely necessary. It is best practice to receive data directly from the source instead of a “third-party”, such as a career site.
Notes:
|
Minimum field requirements
These are the fields we absolutely need to be provided via the Client Job Feed, otherwise, Job Search cannot function properly:
Required Fields |
Notes |
|---|---|
| Job Title: Title of the Job | |
| Job Requisition ID: Unique identifier for jobs. |
Every job’s requisition ID should be unique. If there are two jobs in the client source feed that share the same requisition ID, our scrape tool will identify the duplicate and discard one of the jobs.
Note: If the client cannot assign unique requisition IDs (often due to handling multilingual jobs or accommodating internal and external listings), we can set up multiple feeds to ensure proper data processing. |
| Job Location: Location where the job requisition is posted. |
Required: We require country information.
Recommended:
Note: If the client is uploading and using a location feed, the Location ID field can help match locations from the clients location feed to the requisitions in their job feed.
Multiple Locations: We can support multiple locations per requisition. If this information is known at the time of submitting a request for a job feed ticket, please indicate it in the ticket. For best practice, recommend that clients use the same location field to list multiple locations within a requisition or as an additional location field for clarity. |
| Job Description: Description of the Job (i.e. Responsibilities, Goals, etc.) |
Recommended: Job description data can be provided by clients in a single field, or the data can be split across multiple fields, such as Job Header, Job Description, Job Pay, etc.
Note: We recommend clients send all job description data in a single field, but we do support receiving it in separate fields and can combine them if needed. |
| Job Apply URL: Link to Career site or Application Page for the job. |
This field can either:
Notes:
|
Highly recommended fields
These fields are not required, but are highly recommended to create a more robust candidate job search experience:
Recommended Fields |
Notes |
|---|---|
| Employment Type: Nature of the employment arrangement and the expected work schedule or duration. |
If clients want candidates to be able to search for jobs by employment type (i.e. full-time, part-time, etc) or utilize this data for any unique configurations in the recruiting process, they must send employment type information.
Below are the types of values we accept for this field:
Note: These are the defined fields in our Job Management service. The naming convention within the client’s organization of these values can be shared via the job feed, and they will be mapped to the defined fields during the feed processing layer.
Note: If clients have “intern” or “student” jobs, Employment Type is required. |
| Employment Status: The compensation structure for the role. |
If the client wants candidates to be able to search for jobs by employment status or utilize this data for any unique configurations in the recruiting process, they must send employment type information.
Below are the types of values we accept for this field:
Note: These are the defined fields in our Job Management service. The naming convention within the client’s organization of these values can be shared via the job feed, and they will be mapped to the defined fields during the feed processing layer. |
| Job Category: A broader classification job types (i.e. Job category) |
This field is not required for Job Search to work, but the candidate experience would suffer without it.
Example:
Without a Job Category, if a candidate searches for “Warehouse jobs”, relevant positions, such as “Forklift Supervisor,” may not appear |
| User Fields: Employee information used to assign individuals to job requisitions |
These fields are used to assign specific user roles to certain requisitions, allowing for automatic candidate scheduling and assignment of requisition-based permissions.
Below are the values we accept for this field:
Clients must provide a unique identifier for every user field added (Email, Employee ID, User ID, or Phone Number)
|
Additional fields
These fields are not required, but our Job Search Service can support them:
| Additional Fields | Notes |
|---|---|
| Job Brand: Organization's brand name | This field is commonly used for organizations that recruit for various brands and want to provide distinct candidate experiences. |
| Job Salary: Job's pay rate | This field specifies the expected salary or pay rate for the job (i.e. “$12 per hour”, “10.00”, etc.). |
| Job Internal/External: Whether the job is external or internal |
This field is helpful for clients that offer both internal and external job opportunities and want to delineate which jobs should be available externally (for external applicants) and internally (for current employees).
Note: If the client has both internal and external jobs and wants to delineate which jobs should be available externally and internally, we can use this field to make that distinction. |
| Remote: If the job is a remote position or not |
This field can be specified in a variety of ways, so please request that clients clarify how their remote positions are indicated.
Below are the types of values we accept for this field:
Note: We cannot accommodate specific remote locations (i.e. Remote position in California). Instead, we offer a single Remote location for all remote requisitions. |
| Custom Fields: Other job data |
If clients want to send us job data that does not fit into our pre-defined fields used to power our Job Management service, we can create and map custom fields as needed to handle the data appropriately.
Note: We support all custom fields without any restrictions. |
Sample feeds
IMPORTANT NOTE: This is a SAMPLE – please do not share these resources with clients. This is for INTERNAL reference only.
Sample client source feed
- XML Source Feed
- Example: XML Source Feed Snippet
- JSON Source Feed
- Example: JSON Source Feed Snippet
- CSV Source Feed
- Example: CSV Source Feed Snippet
Sample Paradox mapped feed
We’ve prepared a sample snippet of the Paradox Mapped Feed, which transforms the client source feed into a more easily readable format for our Job Management service.
- Note: This sample is provided in a PDF format and only includes a single job for illustration purposes. This does not represent the actual file used to power our Job Management service. All extracted job information will be included in the Paradox Mapped Feed.
- Example: Paradox Mapped Feed Snippet
Job feed refresh times
The job feed refresh schedules are configured using our Paradox scrape tool.
- Our standard practice is to configure the job feed to run 4 times per day, 6 hours apart, on weekdays ONLY. Reasoning behind this approach:
- Efficiency: Frequent scrapes can overload out systems and impact performance.
- Data Integrity: We maintain past scrapes for auditing and troubleshooting any job feed issues that may arise. Limiting the number of scrapes enables us to maintain these logs and easily reference them in such cases.
Note: While we are willing to consider adjustments to the refresh schedule, reducing the refresh frequency below 2 hours is highly not recommended, but is feasible.
Below are the times when our job feeds will be refreshed (the timezone is UTC). The cron job will run at the 20th minute to avoid the peak time of the server.
| Feed Name | Schedule (UTC timezone) |
|---|---|
| Indeed Apply | 0, 3, 6, 9, 12, 15, 18, 21 |
| Indeed | 1, 5, 9, 13, 17, 21 |
| Google, LinkedIn, Built-In | 2, 6, 10, 14, 18, 22 |
| Talent, Jobcase | 3, 7, 11, 15, 19, 23 |
| Standard | 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23 |
| NAS, EY, RSC, MGMT, PANDO_LOGIC, SYMPHONY | 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22 |
Master feeds refresh schedules
The master feed will only auto-refresh if there is at least one job change (addition, update, or deletion) detected in the source job feeds. If there are no changes, the master feed will not refresh, even if the scheduled refresh time occurs. This is intended to reduce unnecessary processing and ensure the feed only updates when there is new or changed data.
Our auto-synchronization process ensures that the most up-to-date job data from the your job feeds, selected to create our master feed, is accurately reflected in the master feed.
- Refresh Timing: Master Feed refresh process starts at the top of each hour (i.e., 8:00 am, 9:00 am, etc).
- Important Note: The synchronization process does not always complete at a consistent time.
Synchronization process
The synchronization process starts at the top of every hour, where the your account ID is sent to a queue to begin processing. The speed of synchronization depends on the queue size (the number of customer accounts with master feeds requiring an update). A shorter queue results in faster synchronization, while a longer queue may delay the process.
If your Paradox Admin manually refreshes a master feed (i.e., at 8:40 am), then your account ID is immediately added to the queue. If the queue is free, the synchronization process will start right away. Note: The time required for the process to complete may vary depending on when the manual refresh occurs.
For example, if a master feed is manually refreshed at 8:05 am, the process may take longer because it coincides with auto-synchronization for other customer accounts starting at 8:00 am. This variability is reflected in the View History drawer. Each stored version in View History reflects that the feed was refreshed or updated at that time, whether through an auto-update or a manual update.
File creation process
Once synchronization is complete, the system generates and stores a master feed file that is downloadable for users via the View History drawer. The timing of file creation depends on your account's instance. For accounts on the general Olivia production instance, the file creation process runs at the 15th minute of every hour.
- Note: Although the file creation process starts at these times, it does not necessarily finish within the same minute.
Best practices on HTML tags
The following are best practices around HTML tags:
- Replace the “less than” encoded characters
<with actual less than characters:< - Remove all of the newline encoded characters

 - Replace all of the newlines
\nwith paragraph tags around the content<p>...</p> - Include
<html>tags to indicate the text contains HTML
Test your HTML tags and gain more guidance here.
Job Search backup mechanism
When the job crawling session finds 0 jobs, it will return 0. Therefore, the CEM Data Feed – Job will show 0 jobs. When the crawling session returns no job, the backup mechanism will trigger. It will get the data from the nearest success session and then save it to ElasticSearch DB in Job Service.
Why are we setting up that way?
During the crawling session, issues (human error, technical failure, server failure, etc.) may occur and affect search results. To deal with these issues, the Job search service will have a backup mechanism to keep the most recent data session when the crawling session returns nothing.
This can lead to a situation where if the return value is 0 because there actually are no jobs found after the crawling session, the backup mechanism will still be activated because it does not distinguish whether the return value is correct. This leads to data asynchrony.
How do we deal with data asynchrony when it happens?
When this happens, the case will be investigated. When we confirm that this is not an error, the following action will take place:
- If the client understands the scenario and wants to take action by themselves → No action is needed from our side.
- If the client wants these databases (CEM Data Feed and Job Service) to be synchronized, they will make a request, and our developer will manually remove the backup data.
FAQs
How can I tell if a job feed is a live feed or a static feed?
The general rule of thumb is if you can download the file, it is a static file, meaning it will not update/refresh with new jobs. We need a live feed that refreshes jobs so we get new jobs and remove old jobs.
How can CS and/or Implementations validate a job feed is correct?
CS and/or Implementations can validate if a feed is correctly formatted, has all the required fields, etc., if the feed is being transmitted via a public URL. If a feed is being transferred via public URL, anyone can open that URL and see the jobs.
Note: After opening the feed, give it a few seconds and it will auto-format into a readable form. From there, you can scale done the parameters and validate that things like Job Title, Location, Description, etc. are available in the parameters. Use the above sample XML feed/job req as a guide for reading a job feed
Does the job feed need to have user data, such as Hiring Manager or Recruiter?
This is not a requirement; however, some advanced functionality can be unlocked if this is something the client can transfer to us. Some examples of this can include:
- Automate Scheduling via a Group Management and Candidate Journeys (for a non-Hire solution)
- Job Req-Based Permissions
- CC-ing Users on Scheduling/Interview Invites
How frequently do we need to/can we refresh job feeds?
This is highly client-dependent and is driven based on the volume of changes being done to the client’s job postings throughout the day/week (i.e. new jobs added or old jobs removed).
Some rules of thumb:
- Restaurant/Retail clients should have more frequent refreshes because of the high volume of changes being made across many locations (i.e. 2-4 refreshes a day).
- SMB’s typically can suffice with a once-daily refresh, due to the smaller volume of open requisitions, and thus less frequent changes.
- Refreshing during off-peak hours of candidate engagement could get the jobs ready in time for peak candidate engagement, which is typically in mid-mornings and early evenings.
Use your best judgement when advising a client, noting the fact that the more refreshes we run daily, the more taxing it is on our servers. Less is more in most cases because clients will typically exaggerate how frequently changes are actually being made in their ATS.
How can we identify whether a job requisitions is available in multiple locations?
This will typically be identified in some sort of Additional Location field within the Job Feed.
For example, the primary location for the requisitions could be listed under the parameter <location> whereas additional locations will be listed under a <secondary location> or <additional locations> parameter.
How can we set source tracking to job search?
The only form of source tracking we offer today for Job Search is source tracking via URL Source Tag.
A URL Source Tag is a value-added onto every one of the job req Apply URLs that will allow clients to track candidate traffic. Essentially, this URL Source Tag will indicate to the client, on their backend, whether a candidate came in through an Apply Now Job Search click.
That Source Tag looks something like this: “&Source=Paradox_Olivia”
This should be provided by the client to Paradox. Once this is done, one of our engineering team members will appear the tag to all URLs in the client’s job feed and the client can test from there.
My client is posting a job feed via sFTP - what are the configuration steps for this?
- Contact your Paradox Admin to submit a ticket to have an sFTP folder created for the client.
- Send the sFTP credentials provided to you by your Paradox Admin to the client for them to post job feeds to the folder.
- After the client has confirmed that they have successfully sent a job feed file to the sFTP, contact your Paradox Admin to have them submit a Job Search Scrape request.