Security

Statement

Access to the Recruso API is by bearer token over TLS, issued to an API app that is bound to exactly one agency. Isolation between agencies is enforced in the database, below the API, so it holds for every credential and every code path rather than depending on the application applying a filter.

Scope

This page covers the security properties of the API itself and the obligations that fall to you as an integrator. It does not cover the security of the Recruso platform as a whole, nor of the Recruso UI.

Some of what integrators ask about here — a formal SLA, incident notification timescales, a published vulnerability-disclosure process — is not yet stated. See “What we do not guarantee” below, and treat the absence as an absence rather than an implication.

How personal data reached through the API is handled, and what that obliges you to do with it, is covered separately in Data protection.

What we guarantee

Transport. The API is served over TLS and nothing else. Requests over plain HTTP are not supported.

Tenant isolation. Every request is scoped to the agency your credentials belong to, enforced by database-level row filtering beneath the application layer. There is no request parameter, header or credential type that widens that scope, and no token exists that spans agencies. See Multi-tenancy and data isolation.

Non-disclosure of other tenants’ data. A record belonging to another agency is indistinguishable from one that does not exist — both return 404. The API will not confirm the existence of data you cannot see, so it cannot be probed for it.

Short-lived access tokens. Access tokens expire, and the lifetime is returned to you as expiresIn on each exchange. Read that value rather than assuming one; it is the authoritative figure and it can change.

Credentials scoped to an app, not a person. An API app’s credentials — a client id and secret issued as a pair, and an app can hold more than one — belong to the app, so an integration can be revoked without affecting anyone’s user account, and no Recruso user’s password ever reaches your integration. The secret is displayed once, at issue. Writes made through the API are attributed to the Recruso user the app belongs to; disabling that user stops the app from obtaining new tokens.

Optional IP restriction. An API app can be configured with an allow-list of source addresses. A caller outside it is rejected with a 401 regardless of holding a valid secret.

Rate-limited token issuance. Repeated credential exchanges from one address are throttled with a 429, so a leaked secret cannot be exercised at speed. Business operations are not rate limited.

A published compatibility commitment. Version 1 of the API will not break, and anything withdrawn is announced at least twelve months in advance. See Versioning and deprecation.

What we do not guarantee

Stating these plainly is what makes the guarantees above worth relying on.

• There is no sandbox or test environment. Production is the only environment you can call. See Environments and base URLs.
• No availability or response-time commitment is published. There is no SLA on this API today.
• No incident-notification process is published, and no maintenance-window schedule.
• No formal vulnerability-disclosure process is published. Report a suspected security issue to Recruso support, and do so privately.
• Error messages are diagnostic, not a contract. Their wording can change without notice; branch on status codes. See Errors.
• An issued access token cannot be revoked individually. Revoking a secret stops new tokens being issued; tokens already minted from it remain valid until they expire. Plan for that window, and treat a leaked token as live until its expiresIn has elapsed.

Your obligations

The API can only protect what does not leave it. These are yours:

• Never embed a client secret in a browser, mobile app or anything else a user can read. Exchange credentials server-side and keep the resulting token there.
• Store client secrets encrypted at rest, and keep them out of source control, logs and error reports.
• Treat a token as a credential. Anyone holding one can act as your integration until it expires.
• Rotate secrets deliberately rather than only in response to an incident — see Rotate API credentials without downtime.
• Revoke promptly. If a secret may have been exposed, issue a new one and revoke the old one immediately; do not wait for a scheduled rotation.
• Do not cache across credentials. Two tokens are two tenants, and a cache keyed on the path alone will serve one agency’s data to another.

Contact and escalation

Contact Recruso support at support@recruso.co.uk for anything on this page, including suspected security issues. Report those privately and do not disclose them publicly while they are unresolved.

Effective date: 25 August 2026