RecMan API integration: implementation guide
Plan a reliable RecMan API integration for jobs, applications, worker workflows, documents, finance handoffs, caching, security, and support.
A RecMan integration is not complete when one API request returns data.
It is complete when the staffing process still works after a record changes, a field is missing, a downstream platform is unavailable, or the person who built the first version is not online.
That changes the implementation question from “Can we connect to RecMan?” to “Which system owns each record, how does the business process move, and how will the team know when it did not?”
If your company needs help designing and operating that layer, see our RecMan integration services.
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.
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 documents several ways to connect a website with published jobs. A standard career page, a custom domain, filtered links, or a custom API integration may all be valid.
A custom integration is justified when the website needs a controlled experience that the standard path cannot provide: a specific information architecture, combined data, custom filtering, campaign attribution, a different application journey, or additional downstream actions.
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 explicitly notes that its API does not allow browser cross-origin access because client-side use would expose the key.
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.
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.
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 event or schedule that refreshes the data.
Avoid polling every record merely because the API allows it. Fetch with a purpose and preserve enough state to identify what changed.
Treat duplicate and partial updates as normal cases
Networks retry. Users click twice. Webhooks arrive late. A downstream system accepts part of a request and then times out.
Important write operations need idempotency: repeating the same intended action should not create a second candidate, request, document, or invoice. Use stable external identifiers, record the integration attempt, and check the destination before creating another record.
Model partial failure explicitly. If a worker request reaches RecMan but its document does not reach SharePoint, the workflow is not “complete.” It is waiting for recovery, with an owner and a traceable reason.
Make personal-data decisions visible
Recruitment processes handle personal information and may include sensitive categories. The ICO’s recruitment guidance covers responsibility, sourcing, automated decision-making, verification, and record keeping.
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.
The strongest RecMan integration is not the one with the most endpoints. It is the smallest connected process the staffing team can trust and operate.
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.