hireEZ API: public access, docs, and limits in 2026 - 100Hires

The hardest part of a hireEZ API project starts before the first request: finding the current contract.

Our July 16, 2026 audit found current hireEZ connectors and older official API products, but it did not find a current public endpoint catalog for unaffiliated developers.

That finding does not mean private, customer-only, login-gated, or partner APIs are absent. This guide shows how to test access claims and compares the visible hireEZ path with the live 100Hires contract.

Key takeaways

• Current hireEZ evidence is connector-led. Named ATS connections move recruiting data, but an integration page is not a general endpoint catalog.
• hireEZ has documented APIs in the past. Archived pages described custom workflows, Talent Refresh, and resume parsing. Their current public access was not verified.
• The complaint signal is thin. We found no first-hand hireEZ API complaint across Reddit, YouTube, podcasts, X, LinkedIn, or the sales transcripts checked.
• 100Hires publishes a machine-readable contract. Its live OpenAPI 3.1 document covers candidates, jobs, applications, notes, and signed webhooks.
• Access is more than a yes-or-no field. Check documentation, credentials, permissions, limits, events, and the commercial gate one by one.

What the current public evidence says about the hireEZ API

hireEZ clearly connects with recruiting systems. The narrower question is whether a new developer can inspect and call a general API without a negotiated relationship.

Current connectors show data movement, not a general endpoint catalog

Current connector guides describe candidate export, import, enrichment, rediscovery, and profile sync with named ATS products.

The credential often comes from the connected system. A Manatal administrator creates a Manatal token and pastes it into hireEZ. Greenhouse, Recruitee, Workable, and Crelate use similar system-specific setup paths.

Those flows prove that a supported connection can work. They do not show that an unaffiliated developer can obtain a hireEZ key and call arbitrary resources.

The data direction matters too. Some guides describe sending sourced candidates into an ATS. Others describe bringing existing ATS records into hireEZ for rediscovery or enrichment.

A buyer who needs one supported transfer may get everything required from that connector. A developer building a custom data layer needs object schemas, write rules, errors, and change notices that a setup guide rarely supplies.

Archived official pages prove historical API offerings

An official article published in November 2021 described APIs for syncing projects, candidates, and hiring workflows. It framed custom ATS and CRM connections through documentation and partner signup.

A separate archived API Suite page described Talent Refresh and Resume Parsing APIs. Its access path pointed readers toward sales.

These pages answer a historical question: hireEZ documented API products. They do not answer whether a new customer can get the same access now. The old launch URL returned 404 during this audit.

Current hireEZ pages use both 50+ and 100+ integration language in different places. We did not merge those figures. They may count different partner sets, products, or connection types.

Five public-developer fields remain unverified

We did not verify a current first-party public catalog for endpoints, general authentication, rate limits, webhooks, or an unaffiliated developer signup.

Two Help Center routes returned 403. That is an access gate, not proof that the material does not exist. A customer portal or partner program may expose details that public search cannot read.

A third-party directory labels hireEZ with APIs, webhooks, SDKs, and OpenAPI resources. The captured listing did not expose a current first-party contract, so we treated it as a research lead rather than product proof.

In our July 16 sweep of 169 Reddit posts, nine usable video transcripts, two podcast episodes, two X posts, LinkedIn results, and the sales corpus, we found no first-hand API access report.

That zero does not grade the API. It tells us to base the article on visible contracts and gates instead of borrowed complaints about price, sourcing results, or contact data.

Step 1: find a current first-party contract

Start with the vendor's present documentation, not an integration logo or search snippet.

• Find the base URL and API version.
• Look for an endpoint reference or machine-readable schema.
• Check its publication date, version, and changelog.
• Confirm that the vendor owns the page.

The OpenAPI Specification gives software a standard way to describe paths, operations, parameters, schemas, and security.

A product can have a real API yet leave its developer path hard to inspect when access, documentation, and supported operations are spread across separate places.

For hireEZ, our current public search ended at connectors, partner material, gated help pages, historical API pages, and a third-party directory. For 100Hires, the OpenAPI JSON returned 200 without a login.

A useful contract should answer more than “is there an API?” It should let a developer trace one job from discovery to a test request, then show how that request changes when the resource, permission, or version changes.

Save a dated copy of the schema during evaluation. If the vendor later changes a path or field, you have a baseline for review rather than a screenshot of a marketing claim.

Step 2: identify who issues the credential and who approves access

Ask who creates the credential. Then ask who must approve the integration.

Plan gating and partner gating answer different questions. One asks what a subscription includes. The other asks whether the vendor must approve the integration relationship.

A token generated inside Manatal belongs to Manatal, even when it is entered into hireEZ. That setup grants a named connector the permissions documented by Manatal. It does not create a general hireEZ developer key.

The live 100Hires API page documents a different route. A user creates a key under Settings, Integrations, API Keys and sends it in a Bearer header. The same page says access is included in all plans at no extra cost.

That is self-service plan access, not unrestricted access. The company must pass verification, and each key operates within its permissions and rate policy.

For each credential, record the owner, scope, expiry or revocation route, and the environment where it may run. A shared key copied into several automations makes incident response harder, no matter which vendor issued it.

Ask whether the key belongs to a person, a team, or a company. That detail affects staff departures, rotation, and audit ownership.

Step 3: map resources and HTTP methods

Turn broad API language into a resource-method matrix. Check collection routes and single-record routes separately.

The API base is https://api.100hires.com/v2.

The 100Hires entries below come from the live, self-serve /v2/openapi.json OpenAPI snapshot checked July 16, 2026. hireEZ cells stay “not verified” where no current first-party contract was found.

The 100Hires columns come from its live OpenAPI document. Candidates, jobs, applications, and notes each have create, read, update, and delete operations.

Webhook handling is narrower. Job and company webhook routes support listing, creation, deletion, and secret rotation. There is no generic webhook PUT operation, so “full webhook CRUD” would overstate the contract.

Method coverage is not the same as business coverage. A candidate update route may expose only approved fields. An application delete route may require a permission that a read-only integration does not have.

Read request schemas, response schemas, and security rules together. The 100Hires notes-list route requires a documented candidate_id filter. A missing filter makes the request shape incomplete.

Step 4: check authentication, limits, errors, and webhook security

An endpoint list is only the start. Production code needs clear rules for authentication, pagination, errors, limits, and event verification.

The values in this section come from the 100Hires OpenAPI snapshot checked July 16, 2026.

• Authentication: 100Hires documents Bearer keys.
• Pagination: pages start at 1, default to 20 records, and accept up to 100.
• Initial limit: new keys are limited to 100 requests per 10 minutes. Over-limit requests return 429 with limit headers.
• Errors: the contract documents 400, 401, 403, 404, 415, and 429 responses.
• Webhooks: job and company deliveries use POST. Consumers verify HMAC-SHA256 signatures from the x-hires-signature-v2 header.

The OWASP API Security Top 10 is a useful neutral checklist for key storage, authorization, input handling, and exposed data.

The reviewed 100Hires contract does not promise a public sandbox or spell out a retry schedule. Those are fair questions to ask before a production launch.

Rate-limit math needs the unit and the key scope. “100 requests” is incomplete without the 10-minute window, the per-key rule, and the approval state attached to a new key.

Webhook security needs the same care. Record the exact signature header, hash method, secret delivery rule, and rotation call. Test an invalid signature so the receiver fails closed instead of accepting any POST.

Step 5: confirm the commercial and support path

A complete access check ends with the purchasing and support path. Ask four direct questions.

1. Which subscription includes the API?
2. Can an account owner create credentials without a partner application?
3. Which account, company, or security checks must pass?
4. Who approves higher limits or new scopes?

Historical hireEZ pages used partner language and directed readers to sales. Current connectors add plan, administrator, or support conditions. The general current API route remains unresolved in the public sources checked.

100Hires states that API access is included in all plans with no separate API tier. Its documented key flow does not show a partner application step.

Company verification applies, and unapproved keys remain subject to the default rate limit. Contact support about removing limits for an integration.

“Included” answers the subscription question. It does not promise an approved limit increase, every permission, a sandbox, or custom implementation work. Put each item in the agreement or test plan.

For hireEZ, ask for a current reference URL, credential owner, available objects, event list, limit policy, test environment, and support contact. A clear written response can close the public-doc gap for your project.

See the 100Hires REST API v2 walkthrough for the request flow and resource examples.

hireEZ API vs 100Hires API

100Hires publishes this article, so treat its product claims as vendor claims unless the public contract confirms them. The table separates visible evidence from unknown fields.

The products solve different problems. hireEZ centers sourcing and outbound recruiting on top of an ATS. A supported connector may be the shortest route when its data direction matches your process.

100Hires is easier to inspect for custom recruiting-record workflows. Its contract exposes resources, permissions, errors, and event security before coding starts.

Review the 100Hires API overview to inspect the live contract. 100Hires does not reproduce hireEZ's sourcing network or its connector ecosystem.

The visible difference is inspectability, not a grade on technology. A hireEZ buyer may need a connector guide, customer login, partner discussion, or sales response before reaching the same detail.

Worked example: audit a 400-candidate sync

Suppose a recruiting team needs to read 400 candidates, update selected records, and react to new applications.

At the 100Hires default of 20 records per page, the initial read takes 20 list requests. At the documented maximum of 100, it takes 4. Both totals fit inside the initial 100-request window before any updates.

If all 400 records need one update, the maximum-page plan becomes 404 requests: 4 list calls plus 400 writes. At the initial ceiling, that derived total spans at least five 10-minute windows before retries.

A batch worker should watch the documented rate-limit headers and pause at the reset time. It should store completed record IDs so a restart does not repeat successful writes.

The implementation still needs a budget for reads, updates, retries after safe errors, and webhook registration. It must store the Bearer key away from client code and verify every incoming signature.

For hireEZ, the public sources checked do not support an equivalent call count. Send the vendor a concrete request instead:

• Which endpoint lists candidate records, and how does pagination work?
• Can the integration update and delete records, or only export them?
• Which event starts the new-application flow?
• Who issues the key, and which plan or agreement grants it?
• What limit and support path apply in production?

This turns a vague “API available” answer into an implementation decision.

It gives sales and support a testable workload too. A vendor can answer “400 candidate reads and updates plus new-application events” far more precisely than “Do you have an API?”

Common API evaluation mistakes

We found no broad hireEZ developer complaint corpus. These mistakes come from the evidence trail itself, not from inflated user sentiment.

• Treating an integration logo as API proof. A connector can expose one fixed workflow and nothing more.
• Assigning the credential to the wrong vendor. An ATS token entered in hireEZ remains an ATS token.
• Using an archived page as a current contract. Historical capability does not establish current access, support, or limits.
• Reading 403 as “no API.” The page may require a customer login or block automated requests.
• Promoting a directory label into a first-party claim. Follow the label to the vendor's current reference before relying on it.
• Skipping identity checks. The hireEZ query repeatedly surfaced Hirize, a different product with a similar name.

One podcast transcript even returned a complete but mismatched episode. A successful HTTP response proves transport, not source identity or content accuracy.

The same rule applies to API tests. A 200 response from a documentation shell does not prove that the reference content loaded. A 400 response does not prove a route is broken when a required filter is absent.

Keep a small evidence ledger with URL, timestamp, status, owner, and the claim it supports. Mark unknowns as unknown. That habit prevents search snippets and old pages from turning into production assumptions.

Which route fits your integration

Use a native hireEZ connector when your ATS appears in current documentation and the stated data direction matches the workflow.

Ask hireEZ about private or partner access when the connector falls short but its sourcing and outbound platform remains the preferred candidate-sourcing platform.

Choose a public-contract route when developers need to inspect resources, auth, limits, and webhook security before commercial coordination. 100Hires fits that branch when you need control over recruiting records.

This is not a claim that one product replaces the other. It is a choice between a documented connector, a negotiated integration, and a directly inspectable API.

Before choosing, write one sentence that names the system of record, the object that moves, the direction, and the trigger. “Send shortlisted hireEZ candidates to our ATS” may fit a native connector.

“Keep candidates, jobs, applications, notes, and signed events in sync with our internal service” needs broader method and event coverage. That is where a public contract earns its keep.

Frequently asked questions

Does hireEZ have a public API?

Archived official pages document hireEZ API products, including custom recruiting workflows, Talent Refresh, and resume parsing. This audit did not verify a current general self-service reference for unaffiliated developers. Private, customer, login-gated, or partner access may exist. 100Hires provides a public OpenAPI contract for a directly inspectable alternative.

Where can I find hireEZ API documentation?

Public search surfaced current connector pages, partner material, gated Help Center routes, and archived API pages rather than a verified current endpoint catalog. Ask hireEZ for the current first-party reference and access terms. 100Hires publishes its OpenAPI JSON at a public URL without login.

Is a hireEZ ATS integration the same as API access?

No, not by default. A named connector can use the ATS vendor's credential and expose a fixed data flow without granting general developer access to hireEZ. 100Hires documents a Bearer key for its own API, so developers can inspect the resources and permissions attached to that credential.

Does the hireEZ API support webhooks?

This audit did not verify a current first-party hireEZ webhook contract. A third-party directory applies webhook labels, but that is not enough to confirm events, signing, or access. 100Hires documents job and company webhook creation, listing, deletion, secret rotation, and HMAC-SHA256 signature checks.

Is the 100Hires API included on paid plans?

Yes. The live 100Hires API page says access is included in all plans at no extra cost. Users create keys under Settings, Integrations, API Keys; no partner application step is documented in that self-service flow. Company verification and the default 100-requests-per-10-minutes policy for unapproved keys still govern production use.

Get the contract before you commit

hireEZ has current integrations and a documented API history. The public route from current reference to general developer credentials was not verified in this audit.

Request the current contract and access terms, then apply the five checks above. If a public OpenAPI contract and self-service recruiting-record access fit your use case, review 100Hires first.

Create a 100Hires account and test the documented flow after your company is verified.