Why it exists Keeps talent-pool storage lawful and consent-based.
Under GDPR and similar regimes, keeping someone's data after the role they applied for has closed needs a lawful basis, and explicit consent is the cleanest one available. Asking at application time — while the candidate is engaged and the purpose is obvious — produces far higher opt-in rates than trying to obtain consent months later. Canvider then enforces the answer mechanically: non-consenting candidates are excluded from the talent pool and from one-click referral, so an individual recruiter cannot accidentally create a compliance problem.
How to use it
Candidates choose this on the application form when they apply.
Open an applicant's detail page.
Look for "Not open to future opportunities" or "No consent for future opportunities" on the profile.
Candidates without consent are excluded from the talent pool and one-click referral.
Consenting candidates are added to the pool when the vacancy is closed or archived.
Good to know
Check the consent indicator before contacting a past candidate about a new role.
Manually added candidates and bulk-uploaded CVs have not given consent, because they never saw the form.
Without consent you can still approach someone — you just have to do it directly rather than through talent-pool features.
Consent is what makes the talent pool an asset rather than a liability, so it is worth keeping the application form's wording clear.
In-product explanation of how sourced data is handled.
Why it exists Sets expectations and responsibilities before you use sourcing.
Sourcing is the part of recruiting most likely to create a legal or ethical problem, because it involves people who never contacted you and have not agreed to anything. Putting the explanation directly on the page where the data appears — rather than in a policy document nobody opens — means recruiters actually encounter it at the moment it is relevant. It sets out three things worth internalising: results are temporary previews rather than records, LinkedIn data comes through your own account under LinkedIn's terms, and the responsibility for appropriate use is yours.
How to use it
Open the "Discover People" page.
Read the "Privacy & how this data works" panel at the top.
Note that results are temporary previews, not database records.
Note that LinkedIn results come from your own connected account.
Use previews only for legitimate recruiting and respect platform terms.
Good to know
Sourced previews are deleted automatically after 48 hours — Canvider does not build a permanent database of people who never applied.
LinkedIn results are retrieved through your own account, so LinkedIn's terms of use apply to you directly.
Use sourced data for genuine recruiting only; exporting or repurposing it is where teams get into trouble.
Worth reading once with your whole team rather than assuming everyone has.
In-app notice about the limits of AI candidate analysis.
Why it exists Reminds recruiters that humans make the final decision.
Automated decision-making about people is increasingly regulated, and in several jurisdictions candidates have a right not to be rejected purely by an algorithm. Beyond the legal position, there is a practical one: AI scoring is genuinely useful for ranking and genuinely unreliable at the margins, particularly with unconventional careers, career breaks or CVs written in a second language — exactly the candidates a diverse pipeline depends on. The disclaimer sits where the scores are shown because that is the moment the reminder is needed.
How to use it
Open any applicant's Overview tab.
Read the "Candidate Summary" disclaimer text.
Note AI supports but does not replace human judgement.
Verify candidate information independently before deciding.
Read the "FAQ on Data & AI Usage" on the Legal Documents page for more.
Good to know
Never reject a candidate on an AI score alone — review the CV before any negative decision.
AI scoring is least reliable for non-traditional backgrounds, career breaks and CVs written in a second language.
If a candidate asks whether AI was used to assess them, the FAQ on Data & AI Usage is the document to point them to.
Recording your own reasoning in internal comments is what demonstrates a human made the decision.
Candidate data is purged 30 days after a vacancy is deleted.
Why it exists Limits how long candidate data survives after a role ends.
Data-protection principles require that personal data is not kept longer than the purpose requires, and once a vacancy is genuinely gone, the applications attached to it have no remaining purpose. Automatic purging enforces that without depending on anyone remembering. The 30-day delay is a deliberate compromise between compliance and reality — it protects you from an accidental deletion while still guaranteeing the data does not linger indefinitely. Treat it as a countdown: anything you need for records must be exported inside that window.
How to use it
Open the job's details page and click "Change Vacancy Status".
Select "Deleted" and confirm — this cannot be undone.
The vacancy is marked deleted immediately and stops being accessible.
After 30 days, the associated candidate and application data is removed automatically.
Export anything you need for records before the retention window elapses.
Good to know
Deletion is immediate and irreversible from the interface; only the data purge is delayed by 30 days.
Export analytics and any records you need to retain before deleting, not during the 30-day window when you may forget.
Use Archived instead of Deleted for roles you simply want out of the way — archiving keeps the history and feeds the talent pool.
This is also the mechanism that supports a genuine "delete our data" commitment to candidates.
Uploads are validated by type, signature and size.
Why it exists Blocks malicious files disguised as resumes.
An ATS is an unusually attractive target for file-based attacks, because it is one of the few business systems that invites strangers to upload documents. The classic technique is a malicious file renamed with a harmless extension, which is why checking the extension alone is not enough. Canvider inspects the actual file signature — the magic bytes at the start of the file — so a renamed executable is rejected regardless of what it claims to be. Size limits serve a second purpose, protecting the service from upload-based denial of service.
How to use it
Upload files normally through Bulk Upload CVs, Add Candidate or the Files tab.
Canvider checks MIME type and magic bytes, not just the extension.
Files exceeding the size limit (2–10MB depending on the upload) are rejected.
Read the error message and re-upload a valid file if rejected.
Good to know
Renaming a file to .pdf will not get it past the check — the content itself is inspected.
Limits run from 2MB to 10MB depending on the upload point; the Files tab allows up to 10MB.
A rejected legitimate file is usually oversized or genuinely a different format than its name suggests.
This runs on every upload path — bulk CV upload, manual candidate add, application files and profile photos.
Why it exists Prevents brute-force and abusive automated traffic.
Any internet-facing application receives constant automated traffic — credential-stuffing scripts, scrapers and vulnerability scanners probing continuously, entirely independently of anything you do. Rate limiting is the blunt, effective defence: legitimate use never approaches these thresholds, while automated abuse depends on volume and stops being viable without it. It complements account lockout, which protects one account, by protecting the service as a whole from a client attacking many accounts at once.
How to use it
Always on — no configuration needed.
Login attempts are limited to 5 per hour per client.
API requests are limited to 100 per hour.
If you hit a limit, wait for the window to reset and retry.
Good to know
Login is limited to 5 attempts per hour per client; the API to 100 requests per hour.
Normal human use never reaches these limits — hitting one usually means a script or a misconfigured integration.
Relevant if you are building against the MCP API: design for the 100/hour ceiling rather than polling aggressively.
This is separate from account lockout, which locks one account for 30 minutes after 5 failures.