RecMan API integration: implementation guide

Plan a reliable RecMan API integration for jobs, applications, worker workflows, documents, finance handoffs, caching, security, and support.

LeanOrchestr August 21, 2026 9 min read

A RecMan API integration may publish vacancies, register candidates or connect staffing records to another system. Before estimating the build, confirm the operation you need, the key’s permissions and the evidence that will show the record reached its destination.

For a careers website, the answer may be a link to RecMan’s existing pages. For a custom sync, the first useful test is a small, authorized request followed by a controlled failure and recovery. Neither a returned candidate list nor a successful form submission proves the whole staffing process works.

This guide covers implementation decisions around the API. Our RecMan integration services cover scoping, building and supporting the resulting workflow.

Start with the business boundary

Choose one complete outcome before opening the API documentation.

Examples include:

Publish approved vacancies on a branded careers website.
Send applications into the correct recruiting process with attribution.
Give workers a controlled place to view documents and submit requests.
Route approved placement or timesheet data into invoicing.
Produce an operations view without asking recruiters to rebuild a spreadsheet.

Write down the trigger, final result, user, owner, and evidence of completion. This prevents an integration project from becoming a list of endpoints with no operating model.

Verify access and the request contract

RecMan’s access guide places key creation under System settings → Database → API. A system administrator can restrict the key’s operations and modules. Request the access needed for the proposed workflow, then test it with approved records; a key that reads candidates does not prove it can update them.

The documented v2 endpoints are https://api.recman.io/v2/get/ for reads and https://api.recman.io/v2/post/ for writes. Check the scope, operation and required fields in the specific operation reference rather than inferring them from another integration.

For example, candidate insertion uses scope=candidate, operation=insert, corporationId, firstName and lastName; a successful validated insert returns a candidateId. Candidate updates use operation=update and require that identifier. Updating a nested education or employment record also requires its own identifier. Preserve these relationships in the integration’s record of each action.

Read the side effects as well as the fields. The insertion documentation says that adding data to the employee object approves the candidate for staffing. Do not use that object as an arbitrary metadata container.

Keep RecMan authoritative for the records it owns

An integration should not create a second unofficial recruitment database.

Define the source of truth field by field. RecMan may own a candidate, vacancy, company, or placement record. A document platform may own a signed PDF. A finance system may own the posted invoice. A portal may own a temporary user action until that action is accepted by the authoritative system.

For every object, document:

The stable identifier used between systems.
Which system may create or update it.
Which fields are read-only outside the source.
How deletion, archival, and consent changes propagate.
What happens when two systems disagree.

Without those decisions, a successful synchronization can still write the wrong truth to the wrong place.

Choose the simplest suitable website connection

RecMan’s website guide describes hosted career pages, filtered links and custom API integration. A link to the relevant jobs or registration page may already meet the requirement.

A custom integration becomes relevant when the standard route cannot support the required layout, data, filtering or application steps. Verify the intended operations before promising a different candidate experience. For the wider choice between ATS configuration, integration and a new portal, use the staffing software buying guide.

Do not choose custom API work merely to make a standard job list look slightly different. Custom software carries operating responsibility. Use it where that responsibility creates a meaningful business or candidate benefit.

Protect the API key on the server

RecMan’s access guide says it does not enable browser cross-origin access because client-side use would expose the key. Do not put the credential in website JavaScript or solve the browser error by routing it through a public proxy.

The safe shape is:

The browser calls your server-side endpoint.
The server validates the request and the user’s permission.
The server calls RecMan with protected credentials.
The response is minimized to the fields the browser needs.
Logs record status and correlation IDs without exposing secrets or unnecessary personal data.

Limit the API key to the operations and modules required by this workflow. Store it in managed secrets, not source code, public build variables, screenshots, or support messages.

The documented read requests place the key in a query parameter. Configure application logs, error reporting and tracing to redact it before recording a request URL. Check a deliberately failed request as well as a successful one. OWASP’s secrets guidance covers restricted access, rotation/revocation and keeping plaintext secrets out of logs. Agree who replaces a compromised key and how the integration receives the replacement without exposing it.

Check pagination and fields on the first read

The current candidate retrieval reference requires a page number and selected fields. It returns up to 100 candidates per page; a page beyond the available records returns numRows: 0. It also documents an updated filter. The field reference recommends phoneList over the deprecated mobilePhone, homePhone and officePhone fields, although older examples still show them.

A successful first page is only a sample. Check the next page, the last page and a changed record with the permissions intended for production. Ask how timestamps and ordering behave before saving a checkpoint. An updated-since filter alone does not establish deletion propagation or a consistent snapshot while records are changing. Keep a reconciliation process for the data the destination actually needs.

Design caching from freshness and lookup limits

RecMan’s published guidance describes a free daily lookup limit and recommends caching suitable feeds. Confirm the current commercial terms and access limits for your account before launch.

Count requests, not just scheduled runs. In a hypothetical full refresh of 1,200 candidates at 100 per page, one run needs at least 12 requests. An hourly refresh needs at least 288 per day, before empty-page checks, retries or other operations. Those are workload assumptions, not an account allowance. Use observed change volume and required freshness to decide whether a full refresh is appropriate.

Caching is an operating decision, not only a performance trick. A public job list may tolerate a short delay. A recruiter updating a placement may require a near-live result. A nightly finance reconciliation can often use a batch.

For each read path, define:

Maximum acceptable staleness.
Cache key and expiry.
Whether users may see the last known result during an outage.
How closed or withdrawn records leave the cache.
The supported event or schedule that refreshes the data.

Do not assume a webhook exists for every RecMan change. Confirm its coverage and delivery behavior if one is proposed; otherwise budget the polling and reconciliation the workflow needs.

Treat duplicate and partial updates as normal cases

After a write times out, the destination may already have accepted it. Blindly sending the same create request again can produce a duplicate.

Record the initiating event, intended action and returned identifiers. If the outcome is uncertain, check the destination before repeating the write. Do not assume the API provides a native idempotency token unless the specific operation documents and supports one.

RecMan documents candidate creation followed by file attachment as two steps. Consider an illustrative intake flow where the candidate is saved but the file upload fails. Keep the returned candidate ID, show that the attachment is still pending, and recover the missing step. Creating another candidate does not repair the attachment. This is a design example, not a report of a tested customer integration.

Make personal-data decisions visible

Recruitment processes handle personal information and may include sensitive categories. The UK ICO’s recruitment and selection guidance is still labeled draft and under review when checked on 8 September 2026. Use it as a UK-specific reference alongside current advice for the jurisdictions and data involved, not as a universal compliance checklist.

An integration design should therefore identify:

The purpose and lawful basis for each data movement.
The minimum fields needed for the receiving system.
Access rules for candidates, workers, recruiters, clients, and administrators.
Retention and deletion behavior.
Human review where automation influences consequential decisions.
Audit information needed to explain what happened.

Data protection cannot be added after every field is already copied into a convenient reporting database.

Launch with monitoring and reconciliation

An integration needs three levels of visibility.

Technical monitoring answers whether requests, queues, and dependencies are healthy. Workflow monitoring answers which business records are waiting, failed, or need a person. Reconciliation compares authoritative systems and finds records that silently diverged.

A useful operating view includes:

Last successful run and current backlog.
Success, retry, and terminal failure counts.
Records waiting for human input.
Duplicate or validation conflicts.
Credential or permission failures.
A safe replay or manual resolution path.

Then assign an owner. An alert without a responsible person is only a notification.

A practical acceptance checklist

Before launch, verify the full story rather than one API call:

A real user starts the workflow from the real interface.
Authentication and authorization match the intended role.
Data is validated and mapped to stable identifiers.
RecMan and downstream updates are visible in the correct records.
Notifications contain enough context without exposing unnecessary data.
Duplicate submission does not duplicate the business action.
A forced dependency failure produces a visible, recoverable state.
Logs and documentation let another operator diagnose the path.
Retention, privacy, and access decisions match company policy.
The business owner can state how success will be measured.

Keep the test results with the handover: which operations and permissions were used, which records changed, what failed and how it was recovered. If the next operator cannot establish those facts, resolve that gap before adding another workflow. The recruitment workflow guide helps define the business rules around document requests and placement handoffs.

Questions people ask

What can the RecMan API integrate with?

Depending on enabled operations, RecMan data can support job feeds, application routes, worker portals, document workflows, internal reporting, finance handoffs, communication, and other custom systems.

Should a RecMan API key be used in website JavaScript?

No. RecMan states that client-side access would expose the API key. Requests should pass through a server-side integration that protects credentials and limits access.

How should RecMan API usage be managed?

Use only the operations the workflow needs, understand lookup limits, cache suitable read data, avoid unnecessary polling, monitor failures, and reconcile important records.

Can a website use RecMan without a custom API integration?

Yes. RecMan documents links to its hosted career pages, registration and login routes, including pre-applied job filters. Test those options before commissioning a custom feed or application form.