JobDiva API guide 2026: docs, access, and pre-build checks - 100Hires

JobDiva publishes two Swagger 2.0 specification groups through its public API page. This guide shows how to reach them, what those public specs contain, how credential access is documented, and which runtime questions to put to your JobDiva contact before you write code.

Everything below comes from JobDiva's live public documentation and specifications, captured on July 16, 2026, plus third-party integration docs.

We did not test an authenticated JobDiva credential, so runtime behavior stays on the verify list, not the claims list.

This piece is part of our ATS API guides series, where we read vendor API docs so you spend less time hunting for them.

Key takeaways

• Docs are public: the API page renders a Swagger UI whose bootstrap loads full Version 1 (318 paths) and Version 2 (425 paths) specs without credentials; conventional spec URLs return 404 or 401
• Credentials are issued by JobDiva: the public integrations page documents sandbox access for approved partners; other credential routes were not established either way in the sampled public material, so confirm your route with JobDiva
• Two HTTP verbs: both specs are GET and POST only - zero PUT, PATCH, or DELETE across 743 paths, with deletes and updates modeled as verb-named POST endpoints
• No webhooks or rate limits in the specs: neither spec mentions webhooks or documents rate limits, so plan for polling and ask about limits explicitly

JobDiva API documentation and spec URLs

The first thing to know: JobDiva's public API page initially returns a small Swagger UI shell, so a static HTML fetch does not contain endpoint definitions.

In a JavaScript-capable browser, that shell loads public Version 1 and Version 2 Swagger 2.0 specifications through /swagger-resources. The two specs currently expose 318 and 425 path definitions without credentials.

Credentials are still required to call protected API operations, and the public integrations page says approved partners receive sandbox access. More on that in the next section.

The group JSON URLs come through the Swagger UI bootstrap rather than conventional paths. If you try /swagger.json or /v2/api-docs directly, you get 404; /openapi.json returns 401.

So skip curl for the first pass. Open the page in a real browser, pick a version group from the dropdown, and export the JSON from there if you want an offline copy for search and diffing.

The two version groups are published in parallel, and they cover different ground:

• Version 1: reporting-heavy. 213 of its 318 paths (67%) sit under /api/bi/ as report-style read endpoints; the classic resource tags (Candidate, Job, Contact, Company, Submittal) total 33 endpoints
• Version 2: resource-tagged. CandidateV2 carries 111 paths, FinancialV2 94, ContactV2 47, JobV2 41, CompanyV2 26, plus smaller groups

The reporting tilt shows up in the endpoint names themselves. Version 1's DataRetrieval tag carries dozens of candidate read endpoints (CandidateDetail, CandidateActions, CandidateAttachmentDetail, and more), each returning a differently shaped slice of candidate data.

They are useful once you know which report you need.

A new build will likely straddle both groups: v2 for core recruiting objects, v1 for reporting reads. Reading all of this requires no credentials. Calling protected API operations does require them.

Getting JobDiva API credentials

JobDiva's integrations page states that approved partners are granted access to a sandbox environment for developing and testing integrations. The /sandbox URL redirects to that same integrate page, and the site navigation offers a "Submit RFP" path.

No self-serve key-generation flow appears on the public pages we sampled. Other credential routes were not established either way by the public material.

The practical move is simple: confirm the route that applies to you with your JobDiva contact, in writing, before you plan a build timeline.

A product partnership and an internal integration for your own JobDiva account may follow different paths, and only JobDiva can tell you which one is yours.

The auth mechanics are visible in the spec itself. GET /api/authenticate takes three required query parameters: clientid, username, and password. The spec says JobDiva provides the clientid value.

A successful call returns a bare string token, with no structured expiry or refresh metadata documented. Your integration will need to discover the token lifetime empirically.

Third-party setup guides corroborate this credential shape. ZoomInfo's nine-page JobDiva integration guide documents a JobDiva admin creating a dedicated API user with an "Only allow to access JobDiva API Calls" permission.

The person configuring the integration then enters exactly three fields: Client ID, API Username, and API Password.

Dice's partnership terms likewise reference passwords received through the JobDiva API interface. This sample does not establish that OAuth is unavailable - it documents what these two sources describe.

For a feel of the admin side, TextUs's public setup guide walks through the account configuration steps a JobDiva integration expects from an administrator.

JobDiva API methods and data model

743 paths, two HTTP verbs

Here is the count that shapes everything else. Version 1 has 318 paths: 253 GET and 65 POST. Version 2 has 425 paths: 290 GET and 135 POST. Across all 743 paths there are zero PUT, PATCH, or DELETE operations.

Delete and update semantics exist - they are modeled as verb-named POST endpoints in RPC style. You will find operations like DeleteCandidateNotes and UpdatePayRecord rather than DELETE /candidates/{id} or PUT /candidates/{id}.

That means request semantics live in operation names, not HTTP verbs. Standard REST conventions - safe GETs, idempotent PUTs, DELETE meaning delete - do not map cleanly onto this surface.

Two tests worth running early: generate a client from the spec and check what your generator produces from verb-named POST operations, and test the idempotency behavior of update endpoints yourself - the specs do not document it.

Format-wise, both specs are standard Swagger 2.0 REST JSON. Neither contains a SOAP or WSDL reference; we make no claim about surfaces outside these two public specs.

Quirks third-party docs flag

Knit, a unified-API vendor with a JobDiva connector, documents 11 JobDiva operations in developer-facing detail. Two patterns from those docs are worth testing before you commit.

First, date parameters use MM/dd/yyyy HH:mm:ss format rather than ISO 8601. Second, a userFieldsName parameter appears on roughly 6 of the 11 documented operations and is used to retrieve custom fields. Use it when you need those fields, and test the response in your sandbox.

Treat both as things to verify in your own sandbox, not as defects. Third-party docs describe the API as those vendors use it; your build may touch different endpoints.

Webhooks, polling, and event checks

A case-insensitive search of both public specs, run on July 16, 2026, finds zero webhook mentions. Plan on polling unless JobDiva confirms another event mechanism for your account.

Knit's connector documentation describes date-range polling against JobDiva, with fromDate and toDate parameters bounding each pull.

Polling puts three items on your verify list:

• Cadence: neither public spec states a rate limit, so actual limits may exist and need to be asked about before you pick an interval
• Windows: incremental sync runs on updated-date ranges, in that MM/dd/yyyy format
• Tokens: the auth response is a bare string with no documented expiry, so a long-running poller needs its token lifecycle tested empirically

You still need to discuss the sync architecture with your JobDiva contact, since the public docs do not answer every runtime question.

Pre-build verification checklist

Here is the checklist we would use before committing a sprint to a JobDiva integration.

1. Export both specs. Load the API page in a browser, open each version group, and save the JSON for offline reference and diffing
2. Map your objects to a version group. Version 1 is two-thirds reporting reads; Version 2 carries the resource tags. Assume your build straddles both
3. Get your credential route in writing. The public docs establish the approved-partner sandbox path; ask JobDiva which route and timeline applies to you
4. Test the token lifecycle. The documented 200 response is a bare string with no expiry metadata - measure how long tokens live and what authentication failures look like
5. Prototype one write path early. Updates and deletes are verb-named POSTs; check what your HTTP tooling and retry logic do with them, and test idempotency yourself
6. Test date handling and custom fields. Check MM/dd/yyyy HH:mm:ss date parsing and confirm that userFieldsName returns the custom fields you expect on the operations you plan to use
7. Ask about rate limits. Neither public spec states any; your polling design depends on the answer
8. Plan client generation. No official SDK appeared in our sampled top-10 GitHub search, so budget for generating a client from the Swagger JSON and reviewing the output
9. Start the partner conversation early. If your integration ships as a product, the integrate page is where the partner process begins - put it at the front of the timeline, not the end

One honest note on evidence. In our July 2026 sweep of Reddit, X, LinkedIn, YouTube, and podcasts, we found no developer discussion of this API in the samples we collected (r/staffing was unavailable). We did not test a working JobDiva credential ourselves either.

So treat the public docs as the primary source, and verify runtime behavior - latency, error model, practical limits, token lifecycle - in your own sandbox before you base your architecture on it.

JobDiva API vs 100Hires API

Disclosure first: 100Hires publishes this blog. The comparison below applies the same evidence standard to our own API - both public surfaces were captured on the same day, July 16, 2026, from the live specs.

The 100Hires spec doubles as narrative documentation: auth, pagination, error handling, rate limits, and webhook signing are described in the spec text itself, at a URL you can guess.

Every webhook delivery is signed with an x-hires-signature-v2 header (HMAC-SHA256), and secrets rotate with a dual-secret grace window, so a receiver can verify payloads without downtime during rotation.

The same personal API key authenticates REST API v2, webhooks, the Zapier app (3 triggers, 3 actions), and the 100Hires MCP server.

Now the limitations, same standard applied. In the current public spec: auth is a Bearer API key, with OAuth not documented. There is no BI or reporting endpoint layer comparable to JobDiva's /api/bi/ set, and no VMS, timesheet, or back-office domain endpoints.

The 100Hires API surface is smaller: 89 paths compared with JobDiva's 743. Webhook registration is API-only, with no settings-screen UI yet.

That trade cuts both ways. JobDiva's public surface is broader, reaching into VMS, timesheets, and BI reporting. The 100Hires surface covers core ATS objects - candidates, jobs, applications, notes - with full CRUD and documented, signed eventing.

Scale-wise, our own API landing page cites a customer, Linc Healthcare, migrating 25 jobs and roughly 13,800 candidates through the API.

If you need one integration across many ATS platforms, unified-API vendors such as Merge, Knit, and Unified.to publish JobDiva connectors. That architecture differs from a direct integration with one ATS.

If you are choosing an ATS outright rather than planning an integration, see our JobDiva alternatives page.

You can read the 100Hires pricing page or start a free trial; API keys activate once your company passes verification.

Frequently asked questions

Where is the JobDiva API documentation and what does it include?

The docs live at api.jobdiva.com/jobdiva-api.html. The page loads two public Swagger 2.0 groups: Version 1 (318 paths) and Version 2 (425 paths). Reading them needs no credentials. 100Hires publishes its API reference at https://api.100hires.com/v2/openapi.json.

Does JobDiva have a REST API?

Yes. By its public specs, the JobDiva API is a Swagger 2.0 REST JSON surface using only GET and POST verbs; deletes and updates are verb-named POST endpoints such as DeleteCandidateNotes. The 100Hires REST API v2 is documented at the public spec URL above.

Does the JobDiva API support webhooks?

The two public specs contain zero webhook mentions as of July 2026, so plan on polling unless JobDiva confirms another event mechanism. Knit's connector documentation describes date-range polling. 100Hires documents signed webhooks in its public API spec.

How do I get JobDiva API access?

JobDiva's integrations page documents sandbox access for approved partners; other credential routes were not established either way in the sampled public material, so confirm yours with JobDiva. 100Hires API keys are generated in Settings > Integrations after verification.

How much does JobDiva cost per month?

JobDiva does not publish pricing; quotes are customer-specific, and no public API pricing exists either. Request a customer-specific quote from JobDiva through its RFP or demo process. 100Hires publishes its pricing at https://100hires.com/pricing.

Reading an API before you build against it always pays for itself. If your integration focuses on core ATS objects with documented eventing, start a 100Hires trial and begin testing the spec once your company passes verification.