Recruit CRM API in 2026: limits and access - 100Hires

The Recruit CRM API is workable, but do not estimate the build until you confirm Business-plan access, the applicable rate limit, route coverage, and who owns the account token.

Teams reviewing Recruit CRM alternatives should treat this as an integration discovery task, not as proof that the API is broken.

This guide turns the public facts and open questions into a pre-build process. It compares Recruit CRM with the public 100Hires contract, including the points that need account-level confirmation on both sides.

Key takeaways

• Recruit CRM's current official overview says API access requires the Business plan.
• One official page describes a license-based limit. The overview describes 60 requests per minute per API token. The public pages do not reconcile the two scopes.
• The public overview names candidates, companies, contacts, and jobs, plus generic GET, POST, and PUT methods. It is not a complete route-by-route operation list.
• An April 26, 2026 first-party account-settings capture describes one Recruit CRM account-level token. Resetting it interrupts every connected application until each consumer gets the replacement.
• 100Hires publishes a self-serve OpenAPI contract, but its account entitlement and webhook behavior still need confirmation for a production build.

Quick Recruit CRM API comparison

100Hires publishes this comparison. Verify account eligibility and implementation details against current documentation before committing an integration.

This table compares what a developer can inspect before a build. It does not name a throughput winner. A capability not publicly documented may still be available through Recruit CRM support. You can inspect the public 100Hires API contract before requesting access.

What Recruit CRM officially documents

Recruit CRM's official overview provides a useful API starting point. It gives the base URL https://api.recruitcrm.io, shows a /v1/candidates request, uses HTTPS with JSON responses, and places an API token in the authorization header.

The overview states that the Business plan is required.

The overview names candidates, companies, contacts, and jobs. It describes generic GET, POST, and PUT work. That shows records can be read, added, and edited.

The same surface documents an X-RateLimit response header and HTTP 429 when a caller exceeds a limit.

That is enough to prove the API exists. It is not enough to scope every workflow.

The publicly available documentation reviewed did not show a complete route catalog, pagination contract, association model, history access, delete matrix, custom-field rules, webhook contract, SDK, downloadable OpenAPI file, or change policy.

Those points are discovery questions, not missing-feature claims. The next five steps show how to close them before a developer commits to scope or delivery dates.

Prepare a short confirmation packet before contacting support. Include the active plan, the account's license count, a plain-language workflow, the records that must move, expected daily volume, required freshness, and whether writes can be delayed.

Ask Recruit CRM to return the current route list, authentication instructions, limit scope, pagination rules, webhook contract, and one working request and response for each critical action. A dated answer gives engineering and procurement the same baseline.

Step 1: confirm plan access and token ownership

Start with the commercial gate. Ask the account owner to confirm that the active subscription is on the Business plan and that API access is enabled. Do this before a developer writes a proof of concept or promises a client delivery date.

Then map token ownership. An April 26, 2026 first-party account-settings capture describes one token for the account, rather than one per user or application. It says a reset blocks every connected application until each one receives the new value.

• Confirm the exact account plan and API entitlement in writing.
• Ask whether a test account or non-production credential is available.
• Name the person who can view and reset the account token.
• List every existing application that already uses the token.
• Agree on a rotation window, rollback owner, and smoke test.

This is an operating constraint, not a security accusation. An unnoticed spreadsheet script or middleware integration can stop working when another team resets the shared credential.

Step 2: build an operation requirement matrix

A resource name does not tell you which operations are supported. A "Candidates" label does not establish list, item, delete, merge, relationship, history, bulk, or custom-field behavior.

Build one row for each business action instead of estimating from the overview.

Send the finished matrix to Recruit CRM and ask for a current source for every required cell. Include pagination, bulk work, custom fields, relationship rules, activity access, error envelopes, and idempotency.

These details were not documented in the public material reviewed. Do not mark them "no" without a direct answer.

Add fields for request shape, response shape, stable ID, expected status code, and failure action. A route can support the right verb but still return fields in a form that forces extra lookups or prevents a safe match.

For example, "create candidate" is not complete until you know how custom fields are named, which fields are required, how duplicates are handled, and which identifier the next job-linking call expects. Test the full chain, not one isolated request.

Step 3: design for both rate-limit descriptions

Recruit CRM currently has two official descriptions of its limit. The dedicated limit page says accounts with 6 licenses or fewer receive 60 requests per minute.

Above 6 licenses, the dedicated page describes 10 requests per minute for each license. The API overview separately says 60 requests per minute, limited by API token.

The public pages do not explain how license and token scopes interact. Ask which ceiling applies to the account.

Until then, queue work, cap concurrency, log the documented X-RateLimit header, and treat HTTP 429 as normal backpressure.

RFC 6585 section 4 defines the general meaning of HTTP 429. It does not prove that Recruit CRM sends a Retry-After header, uses a specific cooldown, or expects a particular retry formula.

Read and log the actual responses before tuning retries.

Worked example: 400 candidate updates

Suppose a sync needs 400 candidate updates and each update takes one request. Six windows cover only 360 requests at 60 requests per minute, so the planning floor is 7 request windows.

Under the dedicated page's formula, an account with 10 licenses calculates to 100 requests per minute and a floor of 4 windows. But the overview's separate 60-per-token wording may still matter. This is planning math, not a production result.

Response time, 429s, retries, and any confirmed bulk endpoint can change the result. Track queue depth, status codes, request counts, and stable record identifiers. Make writes safe to repeat only where the confirmed contract permits it.

Count supporting reads and writes. A 400-record update may require a lookup before each write, or a paginated list before the batch starts. Your requirement matrix should turn those calls into a low, expected, and worst-case request budget.

Run that budget through the confirmed limit, then test at a smaller rate. Increase concurrency only after the logs show stable responses. This keeps a planning example from becoming an accidental production load test.

Step 4: confirm webhooks or plan a polling fallback

No public Recruit CRM webhook contract appeared in the fetched official material. That is a public-evaluation gap, not proof that webhooks are unavailable. Do not design an event-driven workflow until you receive the current contract for the account and use case.

Send a copy-ready questionnaire. Ask which candidate, job, contact, company, placement, and activity events exist.

• Payload schemas and versioning
• Delivery authentication and secret rotation
• Retry timing, disable rules, ordering, and replay
• Delivery logs and a test-delivery process

If those answers do not arrive in time, design a bounded polling fallback. Poll only the records your workflow needs, save the last successful checkpoint, deduplicate by stable IDs, spread calls through the rate-limit queue, and log every 429 response.

Do not assume Recruit CRM supports an updated-since filter, a cursor, or any specific page model. Confirm those mechanics first. A polling design without a reliable change marker can cost more requests and can miss or repeat work.

Decide how the poller discovers deletions, late changes, and records updated during a long page walk. A periodic full reconciliation may be needed, but its request cost belongs in the rate-limit budget. Record the last completed run, not just the last attempted one.

Keep event and polling adapters behind the same internal interface. If Recruit CRM later confirms a suitable webhook contract, you can replace the trigger without rewriting every downstream field mapping and deduplication rule.

Step 5: plan an account-wide token rotation

A token reset is not a one-application change when every connection shares the account credential. Before rotation, inventory each consumer, its owner, its secret store, and its last successful request.

Remove abandoned consumers from the plan instead of copying the replacement into unknown scripts.

Choose a maintenance window. Update the centralized secret, redeploy or restart consumers as needed, and run a small read test followed by a controlled write test.

Keep a clear rollback owner, but do not assume the old token can be restored unless Recruit CRM confirms that behavior.

The fetched evidence did not establish token expiry, scopes, multiple environments, or a revocation API. Add each item to the vendor questionnaire instead of filling the gap with a standard OAuth assumption.

After rotation, test one low-risk read from every consumer before allowing queued writes to resume. Watch for 401 and 403 responses, then record the rotation date, affected systems, owners, and test results in the integration runbook.

Common Recruit CRM API planning mistakes

• Equating public docs with account access. The current overview says the Business plan is required.
• Flattening the limit statements. Preserve the license-based wording and the separate token-based wording until Recruit CRM explains their relationship.
• Treating an undocumented item as absent. Public search could not verify several mechanics, but support may provide them.
• Estimating complete CRUD from resource names. Confirm each route, method, schema, and relationship your workflow uses.
• Sharing the token without a consumer list. One reset can interrupt every connected application.
• Using generic automation posts as API proof. A workflow that uses Zapier or another connector does not prove native endpoint or webhook behavior.

Reddit discussions did show that agencies care about tool-chain complexity, manual updates, and connector fit. Yet the full research found no qualifying Recruit CRM API-specific complaint, reproducible endpoint defect, or independent reliability report.

The useful criticism is the documented evaluation work, not a claim that developers broadly dislike the product.

How the 100Hires API compares

100Hires publishes a self-serve OpenAPI 3.1 JSON file at https://api.100hires.com/v2/openapi.json. The current contract lists 89 paths and 133 operations: 64 GET, 36 POST, 12 PUT, 3 PATCH, and 18 DELETE operations.

A machine-readable contract makes route inventory easier. A developer can inspect paths, methods, schemas, parameters, response codes, and client-generation options before receiving a working key.

That is the practical value described by the OpenAPI Specification.

Before requesting a working key, a developer can export the 100Hires path list, filter it by candidate, job, application, note, and webhook tags, and mark required methods. That does not replace a test account, but it moves route discovery ahead of account access.

The current 100Hires spec verifies create, read, update, and delete operations across the candidate, job, application, and note resource families.

This does not mean every subresource accepts every method. It gives developers a route-by-route source for building the operation matrix.

The same contract documents 1-based pagination. The page value starts at 1. The size value accepts 1 through 100 and defaults to 20. Response envelopes expose the page, page size, page count, and total count.

Webhook coverage needs precise wording. The spec lists eight job and company webhook management operations for listing, creating, deleting, and rotating secrets. That is not full CRUD.

The OpenAPI specification and the 100Hires webhook guide document HMAC-SHA256 signing, one-time signing secrets, and secret rotation. Neither publishes a retry schedule or delivery guarantee, so handlers should return 2xx quickly and process events idempotently.

Commercial access needs the same care. The 100Hires API page says access is included with paid plans at no extra cost.

The current knowledge base says API keys require a verified company account. Older internal support records contain inconsistent plan-entitlement answers, so they should not be treated as current public policy.

The public contract is self-serve, but verified-company status and working-account eligibility should be confirmed for the planned integration.

100Hires documents a limit of 100 requests per 10 minutes for a new or unapproved key and says support can remove it. The figure is not directly comparable with Recruit CRM's per-minute descriptions. Their windows, scopes, and approval conditions differ.

Review 100Hires pricing, then request a demo with your operation matrix. Ask the team to confirm account enablement, key limits, and webhook delivery behavior against your exact workflow.

When Recruit CRM can still be the right fit

Recruit CRM can fit an agency that already uses the Business plan and has confirmed every required route. It can fit when the expected workload sits within the account's clarified limit and one owner can coordinate token rotation across all consumers.

The public documentation gap does not make the product unusable. It means procurement and engineering need a direct discovery step.

If Recruit CRM supplies the route, pagination, webhook, and operating details your matrix requires, the implementation may be a sensible extension of the agency's existing ATS and CRM workflow.

A public machine-readable contract makes 100Hires easier to inspect before account access. That benefit matters most to a team that wants to estimate the integration effort before speaking with sales or support.

It does not remove the need to confirm 100Hires entitlement and webhook behavior.

Final pre-build checklist

• Written plan entitlement and API enablement
• Test account or safe non-production credentials
• Route and method confirmation for every business action
• Pagination, bulk-work, custom-field, and relationship rules
• Applicable limit, scope, response headers, and 429 handling
• Webhook contract or a bounded polling fallback
• Error envelopes and safe retry behavior
• Token owner, consumer inventory, rotation plan, and rollback owner
• Queue, status-code, limit-header, and failed-sync monitoring
• Written answers for every item that public documentation leaves open

Use this checklist as a handoff between the developer, procurement owner, and implementation lead. For 100Hires, bring it to a technical requirements demo and ask for answers tied to a working account.

Recruit CRM API FAQ

Does Recruit CRM have an API?

Yes. Recruit CRM publishes https://api.recruitcrm.io, token authentication, a Business-plan gate, four data families, and generic GET, POST, and PUT methods. 100Hires publishes a self-serve OpenAPI contract for route-by-route review.

Which Recruit CRM plan includes API access?

Recruit CRM's current official overview says the Business plan is required. The 100Hires API page says access is included with paid plans, while its knowledge base requires a verified company account. Confirm working-account access before production use.

What is the Recruit CRM API rate limit?

One official page says 60 requests per minute for 6 licenses or fewer, then 10 per license above 6. The overview separately says 60 per minute per token. 100Hires documents 100 requests per 10 minutes for a new or unapproved key.

Does Recruit CRM document webhooks?

No public webhook contract was found in the fetched surface. That does not prove Recruit CRM lacks webhooks. 100Hires lists eight job and company webhook management operations, yet its pages conflict on signing and retries. Confirm live behavior for either product.

Is there a public Recruit CRM OpenAPI spec?

No downloadable OpenAPI or Swagger file was found in the fetched official surface. 100Hires publishes a self-serve OpenAPI 3.1 JSON contract with 89 paths and 133 operations.

Is the Recruit CRM API unreliable?

The research found no reproducible independent Recruit CRM API reliability defect, outage, or endpoint complaint. 100Hires needs account and webhook confirmation even with a more inspectable public specification.

Conclusion

Confirm plan access, operations, limits, events, and token ownership before promising a Recruit CRM integration. Its API appears workable based on the public documentation, but several implementation details need direct confirmation.

100Hires offers a more inspectable public contract with its own entitlement and webhook caveats. Inspect the 100Hires API documentation or request a demo to validate your requirement matrix.