Skip to content
Recruit Swipe

For ATS and job board partners

We are a surface on your system, not a replacement for it.

Recruit Swipe never becomes the system of record. Recruiters keep paying you, keep their data in your product, and get a faster way to work through the pipeline that already lives there. Every decision they make writes back to you.

Talk to us about an integrationpartners@recruiterswipe.com

How we integrate

One adapter, server-side, capability-gated.

Every provider implements the same interface: list open requisitions, list candidates on a requisition, fetch a candidate, report capabilities, and — where the provider supports it — advance a stage, reject, add a note, apply a tag.

All HTTP happens on our server. Credentials are held in an encrypted vault, decrypted per call under the recruiter's own session. Nothing reaches the mobile client. Rate limiting, backoff, and retry live in one shared transport, so a busy recruiter cannot turn into a burst against your API.

Writes are gated on declared capabilities. If our adapter cannot verify how an operation works against your API, the product reports it as unsupported and the action is skipped with a visible reason. We would rather ship an honest gap than a write that corrupts a customer's records.

Reads are scoped and cached. We pull the open requisitions a recruiter selects and the candidates on them, cache what the deck needs, and re-fetch on demand. We do not crawl your API for a general candidate database, and we do not sell or pool customer data.

Adding a provider is one adapter file and one client module. When your API is documented and self-serve, we can go from nothing to a working integration in a day.

The ask

What we need from a partner.

  • A sandbox account

    A test tenant with a couple of jobs and some candidates. We record fixtures against it, run our contract tests, and confirm every write actually takes effect in your UI before we tell a customer it works.

  • A straight answer on the endpoints we could not verify

    Each of our adapters has a short list of things the public docs left ambiguous. We would rather ask than guess — and where we have had to guess, the capability is switched off in the product.

  • A listing, when we have earned it

    Once the integration is verified against your sandbox and running with a mutual customer, a spot in your marketplace or partner directory.

Where things stand

Built: 10.

Built means the adapter exists and passes our contract tests. None of these have been exercised against a vendor sandbox yet — that is precisely what we are asking for.

Not on the list?

Tell us about your API