A partnership review usually comes down to two questions: what will this integration do to our API, and what will it do to our customers’ data. Here are both answers.
Endpoints we touch
Reads
- Open requisitions or job postings for the connected account.
- Candidates or applications on a requisition the recruiter has selected.
- One candidate’s detail, when a card is opened.
- Stage or status vocabulary, and tag vocabulary where an endpoint exists.
Writes, only where you support them and only when a recruiter has configured them:
- Move an application to a stage.
- Reject or archive an application, with a reason where required.
- Add a note to a candidate.
- Add a tag to a candidate.
We do not create requisitions, do not create or delete candidates, and do not send messages to candidates.
Volume
Reads are driven by a recruiter opening a requisition, not by a schedule. A deck fetches a page of candidates and pages further as the recruiter works through it.
The one background job is new-candidate detection, and only for requisitions a recruiter explicitly subscribed to. It compares against a stored baseline rather than re-reading everything.
Writes are one to three calls per swipe, bounded by human thumb speed.
Behaviour under pressure
All providers share one transport with exponential backoff, jittered retries on retryable status codes, request timeouts, and a bounded concurrency pool. Rate-limit responses are respected rather than retried immediately.
If your API starts failing, the recruiter sees the failure attached to the swipe with the reason. We do not silently retry into a storm.
Data handling
We cache the requisitions and candidates a recruiter has opened so a deck does not re-fetch on every card. That cache is scoped to the recruiter’s account, protected by row-level policies in the database, and deleted when the connection is deleted.
We do not pool candidate data across customers, do not build a searchable candidate database of our own, do not sell data, and do not train models on it. The security page has the detail; the privacy policy has the commitments in writing.
Attribution
Where your API supports acting on behalf of a specific user — as Greenhouse does — we capture that user at connection time and attribute every write to them, so your customer’s audit trail stays meaningful.