Manatal API in 2026: check access before you build - 100Hires

Manatal documents a broad candidate and job lifecycle, but the first listed plan with API access is Enterprise Plus, and readiness details are spread across pricing, support, a V3 core reference, and a separate webhook surface.

Before engineering starts, verify the plan, token, required resources, webhook events, and production behavior. A successful authentication call is only the first gate.

We found too little current, independent, API-specific developer commentary to support a broad claim that developers dislike Manatal's API. This guide limits criticism to what Manatal's live documentation shows or does not publicly show.

100Hires publishes this guide and owns the API used in the later comparison. The Manatal audit comes first so you can judge each platform on documented behavior.

Key takeaways

• Access: Manatal displays Open API on Enterprise Plus. Custom includes Enterprise Plus features. Support material adds enablement and token conditions.
• Core coverage: the reviewed V3 schema has 72 paths, including candidate and job lifecycle operations.
• Applications: no root applications family appears in the reviewed core schema, but separate form, apply, and refer surfaces exist.
• Webhooks: Manahook is documented separately on a V1 surface with list, create, verify, retrieve, update, and delete operations.
• Operations: pagination is documented. A numeric API rate limit, universal error model, and retry policy are not publicly shown in the reviewed core schema.

Step 1 - confirm the Manatal plan and token path

Start with the commercial gate. If the account cannot expose Open API or issue a working token, endpoint estimates are premature.

Manatal plan prices and API gating

Manatal lists Professional at $19 per user per month or $15 per user per month when billed annually. Enterprise is $39 or $35, and Enterprise Plus is $59 or $55.

Open API appears on Enterprise Plus. Professional and Enterprise do not show it. Custom pricing is not public, but Custom includes everything in Enterprise Plus, including the displayed Open API feature.

Keep three states separate: plan entitlement, feature enablement, and token issuance. Partner setup material is workflow evidence, not proof that every account receives access.

• Confirm the exact plan name and whether Open API is visible.
• Record any support action needed to enable the feature.
• Name the token owner and define a rotation process.
• Ask whether a test environment or token-expiry rule applies. Do not assume either from silence.

Run a read-only token smoke test

The reviewed schema documents the V3 base URL and an API key in the Authorization header with the Token prefix. Use a small read before testing writes.

curl "https://api.manatal.com/open/v3/candidates/?page=1&page_size=1" \
  -H "Authorization: Token <token>"

A successful read confirms that the token can access this endpoint. It does not prove permission for create, update, or delete calls.

Test every intended action on disposable records in an approved environment. Never use a permission audit as a reason to modify or delete production data.

Step 2 - map the resources your integration needs

Translate the business workflow into resources and methods before writing a client. A long endpoint list is useful only when it maps to the actions your integration must complete.

Candidate and job CRUD covers the basic lifecycle

Manatal documents a meaningful candidate and job lifecycle. Both collections support GET and POST. Individual records support GET, PATCH, and DELETE.

Related routes cover activities, attachments, matches, and notes. That breadth matters more than whether an update uses PATCH or PUT. The engineering question is whether the documented request and response shapes match your source of truth.

Application and note modeling changes the build plan

The reviewed core schema does not document a root /applications family. That is not the same as saying Manatal cannot accept applications.

Separate career-page form, apply, and refer surfaces are documented. Notes are nested under several parent resources. Your client must map the intended business object to the right surface instead of assuming a root resource.

For a candidate-to-job workflow, write down each transition: create or find the candidate, find the job, create the documented relationship, attach the note to the correct parent, then identify the event that confirms the change.

Step 3 - verify webhook coverage separately

Do not treat the core V3 reference and webhook documentation as one schema. Manahook is a separate documented V1 surface.

The rendered pages establish those operation types. They do not by themselves answer every production question. Ask for payload samples, event coverage, signing behavior, retry rules, delivery history, secret rotation, and deletion semantics.

What partner demos prove and what they do not

Partner material can show that an integration exists. It does not establish official endpoint coverage, event guarantees, or documentation quality.

It is not proof of official event coverage, delivery guarantees, or documentation quality. Use partner demos to discover test cases, then verify each case against first-party documentation and your own account.

Step 4 - test pagination, errors, and limits

CRUD coverage does not define production behavior. Your test plan needs pagination, error handling, throughput, and recovery.

Manatal documents page and page_size. The reviewed core schema does not publish one universal error model. Record actual success and error responses during testing.

We did not find a numeric API rate limit or a universal retry policy in that schema. General fair-use language should not be converted into a numeric API claim.

• Fetch the first, middle, last, and empty page with a small page_size.
• Record actual response bodies for documented success and error cases.
• Ask support what response indicates throttling and whether Retry-After is used.
• Retry only idempotent operations until write behavior is confirmed.
• Log request IDs, status, latency, object ID, and retry count without storing secrets.

A missing public number is a question, not a defect

No public numeric limit in the reviewed schema does not mean unlimited traffic. Nor does it prove poor reliability.

It means the throughput assumption needs a support answer before load testing. Record the answer with its date, account tier, and approval conditions so the limit becomes an engineering input.

Step 5 - run one full-workflow proof before committing

Build one thin vertical slice before committing to a full sync. Use disposable records and the same sequence the production integration will need.

1. Authenticate and fetch one candidate page.
2. Create a disposable candidate, then read, update, and delete it if those actions are approved.
3. Create or locate a test job and verify the required fields.
4. Use the documented application or relationship surface that matches the workflow.
5. Add a note under the intended parent and confirm it can be read back.
6. Receive one webhook event and test one documented error or retry case.

When Manatal is a good fit

Manatal can be a fit for a team on Enterprise Plus or Custom when its workflow maps to documented candidates, jobs, nested notes, matches, and the separate webhook operations.

The decision becomes stronger when support has confirmed operational details that are not publicly shown. That is a normal procurement and implementation step, not evidence that the API is unusable.

How the 100Hires API compares after the Manatal audit

100Hires publishes this comparison and owns the 100Hires API. The table uses current first-party schemas and access information for both products, with limitations included.

Commercial and documentation access

Manatal's main commercial constraint is plan placement. 100Hires includes API entitlement on paid plans, but entitlement is not instant usability: the company must be verified or the key returns 401.

The documentation path differs too. Manatal has a live reference, but readiness facts sit across several surfaces. 100Hires exposes a self-serve API documentation page and OpenAPI JSON.

An OpenAPI specification can feed code generation and validation tools. A downloadable file reduces discovery work, but it does not replace account verification or live testing.

Resource and webhook modeling

100Hires documents root CRUD for candidates, jobs, applications, and notes. That model can be easier to inspect when those four resources form the center of an integration.

Its webhook surface is narrower than generic CRUD. Routes are scoped under jobs and companies, with list, create, delete, and secret rotation. The reviewed schema does not expose a generic webhook PUT or PATCH route.

Manatal offers a broad candidate and job lifecycle, nested notes, separate application surfaces, and a separate webhook API. Neither structure is universally better. The better fit is the one that matches your objects and event flow.

When 100Hires is easier to evaluate

100Hires is easier to evaluate when you want a downloadable schema, root application and note resources, and a documented default limit before speaking with a partner team.

You still need company verification, and webhook routes are bounded. Review the 100Hires webhook guide alongside the schema before choosing it.

Common Manatal API evaluation mistakes

The main risks come from skipping gates or turning documentation silence into a product claim.

• Estimating before access: confirm Enterprise Plus or Custom, enablement, and token issuance first.
• Treating a partner demo as entitlement proof: use it to learn a workflow, then confirm access on your account.
• Combining V3 and V1 into one schema: inventory core and webhook surfaces separately.
• Calling a missing root path missing functionality: check the separate form, apply, and refer surfaces before reaching a conclusion.
• Turning fair use into a numeric limit: ask for the actual throughput rule and record the answer.

These corrections keep the evaluation constructive. They produce a better engineering estimate: each unknown becomes a named test or support question.

Pricing and API access parity

This table compares API-access economics, not total product value. Manatal prices are per user. 100Hires prices are in USD per account for the 1-20 employee option selected when the page was checked.

Monthly and annual-billed monthly figures were displayed when checked. Annual totals below are arithmetic and marked derived. See current 100Hires pricing before buying.

A team-size example shows why scope matters. Ten Manatal Enterprise Plus users cost $550 per month at the displayed annual-billed rate, or a derived $6,600 per year. The 100Hires account prices in this table are not calculated per recruiter seat.

Frequently asked questions

Which Manatal plan includes API access?

Enterprise Plus is Manatal's first listed plan with Open API. Custom includes everything in Enterprise Plus, so it inherits that feature. 100Hires includes API entitlement on paid plans, but the company must be verified before its key works.

Which Manahook V1 webhook operations can a developer manage, and what must be verified before production?

Manahook documentation shows list, create, verify, retrieve, PATCH, and delete operations on a separate V1 surface. Before production, verify event coverage, payloads, signing, retries, and delivery history. 100Hires documents job- and company-scoped webhook list, create, delete, and secret-rotation routes, not generic webhook CRUD.

Does Manatal have an applications endpoint?

The reviewed Manatal core V3 schema has no root applications family. Separate career-page form, apply, and refer surfaces exist. 100Hires documents root applications collection and item CRUD. Verify which model fits your workflow before building.

Is there a public Manatal OpenAPI file?

Manatal has a live API reference, but direct registry-download routes did not return a public JSON file during research. 100Hires exposes a self-serve OpenAPI 3.1 document at https://api.100hires.com/v2/openapi.json.

What is the Manatal API rate limit?

No numeric limit was publicly shown in the reviewed Manatal core schema, so confirm it with support before load testing. 100Hires documents a default of 100 requests per 10 minutes for unapproved keys, with company verification still required.

Build only after the readiness check passes

Manatal can support an integration whose required workflow maps to its documented resources once Enterprise Plus or Custom access is confirmed. Public operational gaps remain support and test questions, not grounds for an invented defect list.

100Hires offers a more self-serve evaluation path for teams that want a downloadable OpenAPI file and root candidates, jobs, applications, and notes resources. It still requires company verification and has scoped webhook routes.

Inspect the 100Hires API, then start a free trial if that resource model matches your integration.