Monster job posting API: the SOAP gateway, the search API, and who can actually use them

Search for “Monster job posting API” and you land on two completely different products that happen to share a name. One posts jobs into Monster: a SOAP gateway called Real Time Posting that employers and ATS vendors use to publish, update, and expire listings. The other reads job postings out of Monster: a token-authenticated search API at api.jobs.com.

Monster documents and sells the first one heavily. Most developers typing that query want the second. Both are real, both are partner-gated, and only one of them does what you probably came for. This post maps every Monster developer surface to the direction it moves data and the door you have to knock on to use it.

The direction test

This is the same split we mapped for Indeed, with one important difference. Indeed’s program is entirely write-side: the four Indeed partner APIs all publish data into Indeed, and no official read API exists at all, which is why the Indeed API guide spends most of its length on what you do instead. Monster is different. A read API genuinely exists. It is just not self-serve.

Five of the seven move data toward Monster. If your goal is a feed of listings you can query, only the last row matters, and the row above it is the one people most often click by mistake: the Candidate Search API searches resumes, not jobs.

Real Time Posting: the SOAP gateway

RTP is what Monster means by a job posting API. It is SOAP over HTTPS, not REST, and it posts to a single endpoint: https://gateway.monster.com:8443/bgwBroker. The non-standard port is the first thing to check, because outbound 8443 is blocked by default on plenty of corporate networks and container egress policies.

Authentication is WS-Security. There is no bearer token and no API key header; your credentials travel inside the SOAP envelope as a wsse:UsernameToken with wsse:Username and wsse:Password children, sitting in a wsse:Security block in the header alongside Monster’s own MonsterHeader element carrying a message id and timestamp.

The body root is a Job element in the http://schemas.monster.com/Monster namespace, validated against Job.xsd under http://schemas.monster.com/Current/XSD/. The payload must be UTF-8, and special characters inside the job description need CDATA wrapping. Here is a trimmed, illustrative envelope - the authoritative element order and the full attribute set come from the XSD, not from this snippet:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
  <SOAP-ENV:Header>
    <wsse:Security>
      <wsse:UsernameToken>
        <wsse:Username>YOUR_RTP_USERNAME</wsse:Username>
        <wsse:Password>YOUR_RTP_PASSWORD</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <Job xmlns="http://schemas.monster.com/Monster"
         jobRefCode="ENG-4471"
         jobAction="addOrUpdate"
         inventoryType="Transactional">
      <RecruiterReference>
        <UserName>YOUR_MONSTER_USERNAME</UserName>
      </RecruiterReference>
      <JobInformation>
        <JobTitle>Senior Backend Engineer</JobTitle>
        <JobBody><![CDATA[Own our ingestion pipeline end to end...]]></JobBody>
      </JobInformation>
      <JobPostings>
        <JobPosting desiredDuration="30">
          <Location>
            <City>Boston</City>
            <State>MA</State>
            <CountryCode>US</CountryCode>
            <PostalCode>02110</PostalCode>
          </Location>
          <BoardName monsterId="1"/>
        </JobPosting>
      </JobPostings>
    </Job>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The field rules that bite in practice:

• jobRefCode is your unique identifier, capped at 50 characters. Change it and you create a second job; the original does not auto-expire.
• JobTitle is capped at 100 characters and JobBody has a 25 character minimum.
• Enumerated fields such as JobStatus and BoardName are not free text. They carry a monsterId attribute whose legal values live in Enumerations.xsd.
• Location wants city, state, country code, and postal code at minimum. Multiple locations mean multiple JobPosting elements.

Updating and expiring

There is no PATCH. Updating a live job means resubmitting the same envelope with the same jobRefCode and jobAction="addOrUpdate", which is why that action is the one to standardize on rather than the separate add and update variants. Expiring a job means either setting the delete action or posting a separate Delete request built against Delete.xsd, keyed on the reference code or the posting id.

Two timing details worth designing around: a posted job typically becomes searchable within about 90 minutes rather than instantly, and a deleted job remains searchable until the search index catches up. Neither is a bug, but both break naive read-after-write assertions in your integration tests.

What SOAP on 8443 actually costs you

None of this is unreasonable engineering. It is a stable, documented, schema-validated interface, and schema validation catches malformed payloads earlier than a loosely typed JSON body would. The cost is that the surrounding ecosystem has thinned out.

In a modern Node, Python, or Go service you will most likely build the envelope by hand rather than generating a client from the WSDL, because maintained SOAP tooling is scarcer than it was. You need an egress rule for port 8443. Errors arrive as XML fault documents you have to parse and map to your own error taxonomy. And you cannot smoke test without credentials, so the whole integration is blocked until a Monster representative issues them.

Budget days, not an afternoon. That is the honest comparison against a JSON REST posting API, and it is the same trade the rest of the distribution world makes; see what a job posting API is for how the category splits between write-side distribution and read-side data.

The feed route in: Aggregated and Organic Jobs

If you have thousands of jobs rather than dozens, Monster steers you to a file feed instead of RTP. The rules are specific: XML or JSON files only, 50MB maximum per file with larger feeds split across parts inside a compressed archive, and one update per 24 hour period.

Each job needs a title, a description of at least 200 characters, a company name, a unique reference code, a location as country, state, and city, and an application URL. Salary, remote or onsite status, and posted date are optional. Because it is a pay-per-click channel, you can set bids at the individual job level or across a campaign, and you can wire Apply With Monster so applications arrive at a REST endpoint or an inbox.

The 24 hour cadence is the design constraint. If your ATS produces near-real-time changes, the feed will always lag it, which is the same staleness problem covered in ATS API integration.

The Job Search API: the only read path

Monster does document a read surface, and it is worth knowing it exists because most write-ups of this topic miss it. You GET or POST to https://api.jobs.com/v3/search/jobs and get JSON by default, or XML if you send an Accept: application/xml header.

Auth is a two-step token exchange rather than a static key. You POST to https://api.jobs.com/auth/token with an AppId and an AppSecret, receive a token plus an expiry timestamp, and then send Authorization: bearer with the token on every search. Plan for refresh on expiry rather than caching the token forever.

The query surface is reasonable for a board search API:

• country is the one required parameter. There is no global “everything” query.
• Filters include title, keywords, skills, company, state, city, postalcode, radius, age, jobType, boardIds, and mesco for O*NET style occupation codes.
• orderBy takes latest or relevancy.
• Paging is page and perPage, and the total match count comes back in a TotalHits response header.

The hard ceiling is the one to plan around: a single query returns at most 1000 jobs. That is a search API, not a bulk export. Building a corpus means slicing the space into many narrow queries by geography, title, and age, which is a familiar tax if you have worked with any board search endpoint.

And the access model is the real gate. The documentation describes credentials as Monster-provided and never describes a self-serve signup, which puts it squarely on the gated side of the line drawn in public versus gated ATS APIs. You can read the full spec today. You cannot call it today.

Who owns Monster now, and why it matters

Anyone planning a Monster integration in 2026 should know what the company went through, because it changes how you scope the risk.

• September 2024: the CareerBuilder and Monster job boards combined, with Apollo Global Management holding a controlling interest and Monster owner Randstad taking a minority stake.
• June 2025: the combined CareerBuilder + Monster filed for Chapter 11 and put its businesses up for sale, after revenue fell nearly 40 percent from its post-pandemic peak.
• July 2025: JobGet opened as stalking horse bidder at 7 million dollars and raised to about 27 million. Bold Holdings won the auction at 28.4 million dollars.
• 1 August 2025: Bold completed the acquisition of the CareerBuilder + Monster job board assets, extending offers to roughly 350 staff. The Monster Media Properties and Monster Government Solutions units went to separate buyers in transactions that closed the day before.

Bold runs Zety, LiveCareer, MyPerfectResume, FlexJobs, and Bold.pro, and says Monster and CareerBuilder will continue as standalone brands. So the practical answer is: the boards are alive, the docs are up, and the partner program is a going concern.

What changed is the continuity assumption. A partner program that has just passed through a bankruptcy, a sale, and a headcount reset carries more roadmap risk than one that has not, because roadmaps get re-set when owners do. No deprecation of RTP or the Job Search API has been announced, and it would be wrong to imply otherwise. The reasonable move is to get API commitments written into your partner agreement, and to avoid architecting a system whose only data path is one board’s partner API.

Reading the public job market without a partner agreement

If you got here because you wanted job postings rather than a way to publish them, the gate is the problem, not the protocol. Monster’s read API exists but is issued by a sales conversation, and the same is true across most large boards, which is why where to get job posting data keeps coming back to aggregation.

That is what JobsPipe does. We index public job postings from 30 or more sources - Indeed, LinkedIn, Workday, Greenhouse, Lever, Glassdoor, Dice, ZipRecruiter, Ashby, SmartRecruiters and others - and normalize them to one schema behind one endpoint with a self-serve key. To be explicit about what we are not: JobsPipe does not resell Monster’s proprietary feed and has no Monster partnership. What you get is broad coverage of the public job market, queried the same way regardless of where a posting came from.

curl -X POST https://api.jobspipe.dev/v1/jobs/search \
  -H "Authorization: Bearer jp_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "job_title_or": ["backend engineer", "platform engineer"],
    "job_country_code_or": ["us"],
    "job_location_or": ["Boston"],
    "posted_at_max_age_days": 7,
    "include_total_results": true,
    "limit": 50
  }'

The response is a metadata object with total_results and next_cursor, plus a data array of normalized postings: title, company, location, country, a compensation object, seniority, posted date, a stable id, and an apply_url. No token exchange, no 1000-job ceiling on the corpus, and no XSD. The free tier is 100 requests a month, and there is a keyless sandbox endpoint if you want to see the shape before signing up. The wider argument for consolidating boards behind one contract is in unified API job data.