CATSOne API vs 100Hires in 2026: limits, webhooks, and alternatives

The CATSOne API is a real, broad recruiting API with Token authentication, candidate and job CRUD, pagination, a documented rate limit, and optional HMAC-signed webhooks.

This guide compares the CATS public contract with 100Hires and identifies the questions a proof of concept must answer.

We searched developer communities, videos, podcasts, social posts, current documentation, and our sales corpus for first-hand CATS API experiences.

The public developer voice was too sparse to support a verdict that developers broadly like or dislike CATS.

If your existing CATS workflow covers the objects and events you need, keeping it may be the practical choice.

If you are starting a two-way integration across candidates, jobs, applications, and notes, the inspectable 100Hires API reference may reduce the work needed to understand the API. Neither option removes the need for a proof of concept.

CATSOne API vs 100Hires API at a glance

These request limits use different windows. A simple hourly conversion would hide burst behavior, so neither product is a universal throughput winner from the headline figures alone. Model your actual backfill, polling, and webhook traffic.

One distinction matters throughout this guide: not publicly documented does not mean unsupported. It means the reviewed public material did not settle the question.

A machine-readable contract based on the OpenAPI Specification makes more of those questions testable before credentials are issued.

100Hires has a documentation inconsistency worth knowing.

An older webhook marketing page says raw webhooks lack a signing secret, but the current OpenAPI documents signed delivery and secret rotation. We use the live OpenAPI as the technical source of truth here.

What the CATS API documents well

CATS is not a thin API hidden behind a one-page integration pitch.

Its v3 reference covers candidates, companies, contacts, jobs, pipelines, portals, activities, attachments, tasks, triggers, users, phones, emails, work history, and webhooks.

Broad recruiting resources and predictable pagination

Candidate and job routes support the core list, read, create, update, and delete operations. Related routes cover attachments, fields, tags, applications, activities, and work history.

That is enough surface area for many sourcing, portal, reporting, and workflow integrations.

Pagination is consistent at the contract level. Requests use page and per_page, starting at page 1 with 25 records by default and a maximum of 100.

Responses expose counts, totals, links, and embedded records. Limit and remaining headers let a client slow down before it receives HTTP 429.

The rate limit is 500 requests per rolling hour. That figure is concrete enough to design a queue, estimate a backfill, and decide whether polling is realistic. It deserves load testing when one user action can trigger several related reads.

A more detailed webhook contract than the headline suggests

CATS documents 25 webhook event values across created, updated, deleted, and status-changed records. Webhooks can be listed, read, created, and deleted through the API.

A secret is optional but strongly recommended. The signature scheme uses HMAC-SHA256 over the raw request body plus the request ID.

The delivery notes are unusually specific. The triggered record can arrive in the webhook payload, which can include more embedded data than an ordinary API response.

A mass update emits one webhook for every affected record. That warning gives teams a reason to queue events and acknowledge them quickly instead of doing heavy work in the request handler.

CATS documents a failure threshold. After it receives 50 consecutive bad responses, such as HTTP 500 responses or timeouts, within 30 minutes, it disables that webhook and emails the user.

This is a disable rule, not a published retry schedule. We did not find a public delivery-history or replay API in the reviewed reference.

Seven CATS API questions to resolve before you build

The public reference answers many endpoint questions. The remaining work is mostly about account entitlement, operations, and whether the documented resource shapes match your source-of-truth model.

1. Is API access enabled for your account?

CATS documents creating an API key from Administration settings, but the public pricing page we reviewed does not state which accounts receive API access.

A small number of forum questions ask about missing v3 access or sandbox setup. They show that some users needed clarification, not that access is universally gated.

Confirm production entitlement, sandbox availability, and who can see the key before you estimate the integration. An endpoint inventory does not help if the target account or test environment is not ready.

2. Who owns, rotates, and revokes production keys?

The Token authentication scheme is clear. The public lifecycle around that token is not. We did not verify a public procedure for ownership scope, rotation, revocation, or handoff when an employee leaves.

That does not prove the controls are missing. It means the security runbook needs an account-level answer. Name an internal owner, store the key in a secret manager, record which workloads use it, and test replacement before the first incident or offboarding event.

3. Does the rolling-hour window fit burst traffic?

A 500-request rolling-hour allowance may be comfortable for a low-frequency synchronization and tight for a historical import. The important variable is fan-out. Reading 100 candidates can lead to separate requests for activities, attachments, applications, or custom data.

Use the remaining-limit header, centralize request scheduling, and back off on 429 responses. Test the busiest ten-minute interval rather than the daily average. If polling is frequent, compare that design with event-driven updates before launch.

4. Do you need generic application writes or standalone notes?

CATS has broad candidate and job CRUD. Application coverage is more specific.

General application routes are read-oriented, but a portal-scoped route submits an application for a job on a particular portal.

The API can create an application through that route, but the reviewed contract does not expose generic application CRUD.

The reviewed contract has no standalone notes resource. Candidate and job records can contain a notes field, and activities can carry note-like content.

Write down each required object, direction, and source of truth. A one-way careers-site intake can fit the portal route. A two-way application synchronizer with independent note IDs, updates, and deletions needs a proof of concept against the real account.

5. How will you change webhook configuration?

The reference lists GET, POST, and DELETE operations for webhooks, but no PUT or PATCH route. If an endpoint URL, event set, or secret must change, determine whether your account workflow expects deletion and recreation or offers another supported path.

Treat that as an operational test, not an assumed limitation. Your runbook should cover the short interval when an old webhook is removed and a replacement begins receiving events.

6. Can your tooling consume the public contract?

The CATS reference is detailed and includes examples, but we did not verify a public OpenAPI file or first-party SDK package. That changes the kind of work required.

Teams may need to maintain request and response models by hand, write their own client wrapper, and build contract tests around the fields they use.

The latest entry displayed in the public changelog is version 3.0.21 from Winter 2019. That is a documentation-freshness concern, not evidence that the API stopped changing.

Ask how breaking changes are announced, subscribe to the available update channels, and compare live responses with your stored fixtures.

7. What happens after a failed delivery or validation error?

CATS documents several error statuses and invalid-field feedback, but the reviewed material does not establish one universal error envelope for every route. Webhooks have a clear disable threshold, yet no public retry cadence, delivery log, or replay endpoint was found.

Design for the part you control. Store request and event IDs, log response bodies safely, make consumers idempotent, alert before a long outage reaches the disable threshold, and run contract tests against representative validation failures.

How the 100Hires API compares in practice

The 100Hires API is easier to inspect before implementation: its current machine-readable contract is public.

The live OpenAPI 3.1 document contains 89 paths and 133 HTTP operations. Those are different counting units from the public phrase “100+ endpoints,” so the totals do not conflict.

Self-serve schema and four-object CRUD

The primary candidate, job, application, and note collections each expose create and list operations. Their item routes expose read, update, and delete operations.

For a two-way ATS synchronization, that removes two important CATS questions: generic application writes and standalone note records.

OpenAPI gives a team a schema to inspect, import into API tools, and use as an input for client generation. It does not mean 100Hires ships a verified first-party SDK.

Generated clients still need review, authentication handling, pagination logic, error tests, and product-specific workflows.

Coverage extends beyond the four primary objects to interviews, messages, files, career-site operations, status changes, hiring teams, batch actions, and related records.

Some company-management and company-level webhook operations have partner-related access restrictions. An operation appearing in the spec does not grant every key permission to call it.

Signed scoped webhooks and secret rotation

100Hires webhooks sit under jobs and companies rather than a top-level collection. The contract documents listing, creation, deletion, signed delivery, and secret rotation.

A secret is returned once. Rotation can preserve the previous secret during a grace window, when more than one signature may be valid.

That is a clearer secret lifecycle than the public CATS material we reviewed. It is not a complete delivery-operations story.

We did not find a published provider retry count, backoff schedule, replay control, or delivery-history endpoint in the 100Hires contract.

Consumers still need quick acknowledgements, asynchronous work, idempotency, and their own event log.

Access is explicit, not unlimited

The public API page says access is included on all 100Hires plans at no extra cost. That removes a separate API-tier question. It does not remove account controls.

Keys are tied to a user and company. They remain disabled until the company is verified.

New keys have a hard limit of 100 requests per 10 minutes, and support may remove it after reviewing the integration use case. Endpoint permissions can return 403, especially for partner-company operations.

API-key revocation is documented, but dedicated API-key rotation is not.

The OpenAPI describes validation failures in two conflicting ways. One section uses success: false with field-level errors; another uses an error object plus validation_errors.

Test the operations you depend on instead of coding to one promised universal envelope.

The older webhook marketing page calls raw webhooks unsigned. That statement conflicts with the current signed-webhook and secret-rotation operations.

This comparison relies on the live OpenAPI, but the inconsistency remains a documentation problem.

Keep CATS or consider 100Hires? Use this build checklist

Switching products involves more than comparing APIs. Existing workflows, data migration, recruiter training, and downstream integrations may matter more than a cleaner contract. Use a short proof of concept to separate a documentation inconvenience from a real blocker.

Keep CATS when its broad resource model and event catalog support a reliable integration, and when the operational cost of switching outweighs the remaining questions.

Review CATS alternatives when an essential write flow, account-access requirement, or tooling requirement becomes a genuine blocker rather than a preference.

Consider 100Hires when a new integration needs a self-serve schema, four-object CRUD, a public statement that API access is included on all plans, and webhook-secret rotation.

Keep its limitations in mind when deciding: verification, a default new-key window, permission checks, no documented API-key rotation, no published retry or replay contract, and inconsistent validation-error descriptions.

CATSOne API FAQ

Does CATS have an API?

Yes. CATS publishes a v3 API reference with Token authentication, recruiting resources, candidate and job CRUD, pagination, rate-limit guidance, and webhooks. Confirm account entitlement. 100Hires publishes a live OpenAPI contract for comparison.

What is the CATS API rate limit?

CATS documents 500 requests per rolling hour, HTTP 429, and limit headers. Queue large imports and monitor the headers. 100Hires starts new keys at 100 requests per 10 minutes, so compare the two windows against your traffic pattern.

Does CATS support webhooks?

CATS documents list, read, create, and delete webhook operations, 25 event values, optional HMAC signing, embedded payloads, and a failure-disable threshold. Public retry and delivery-history details are not documented. 100Hires documents signed deliveries and secret rotation.

Can the CATS API create applications and notes?

CATS documents portal-scoped application submission, but its general application routes are read-oriented rather than full generic CRUD. No standalone notes resource is documented. 100Hires documents full CRUD for applications and notes.

Is the 100Hires API included on paid plans?

The public 100Hires API page says access is included on all plans at no extra cost. Keys still require company verification, new keys start with a 100-request-per-10-minute limit, and some operations require additional permissions.

Which API is easier for a new two-way ATS integration in 2026?

100Hires is easier to inspect for two-way candidate, job, application, and note CRUD: its OpenAPI exposes those operations. CATS may fit better when it is already embedded in your workflow and its resources and events meet your needs. Validate either with a proof of concept.

Test the integration before you choose

Map the objects you read and write, the busiest request window, the events you consume, the signature workflow, and the account permissions you need. Then test one complete path with realistic failures before making a migration decision.

If you want to compare that plan with the live 100Hires contract, review your integration requirements with 100Hires. Bring the object map and expected volume so the discussion stays technical.