Talent SummonerATS Integration Evaluation Checklist
Use this ATS integration checklist to compare APIs, webhooks, data, security, failures, support and implementation risk before buying.
An ATS integration can look complete in a demo and still omit a required field, create duplicates or leave a failed webhook invisible. Use this checklist at selection with the same role, test records and acceptance path. Ask for written answers, current documentation and a named owner for each unknown.
This is a procurement aid, not legal, security or privacy advice. Have data, security and legal owners confirm requirements for your locations, candidates and contract.
Define the boundary
Write one sentence describing the hand-off: source system, receiving ATS, trigger, direction, records, owner and proof of completion. Distinguish a native connector, direct API, partner service, scheduled export and manual link. Each has a different maintenance burden.
| Path | Small-team advantage | Trade-off to price | Select when |
|---|---|---|---|
| Native connector | Less initial build | Plan limits, vendor release changes and support dependency | Required fields and recovery evidence pass the test |
| API and webhooks | Precise control and fresh status | Build, secrets, monitoring, retries and schema maintenance | A technical owner can operate it |
| Partner platform | Less custom code | Second contract, data path, rate limits and incident hand-off | Partner security and exit terms are documented |
| Export/import | Low initial engineering | Lag, duplicate review, restricted files and manual mapping | A human-verified delay is acceptable |
| Custom service | Fits unusual workflow | Highest build, security, maintenance and replacement burden | The workflow is funded and owned after launch |
Select the least complex path that passes the gates. Ask: what work disappears, what work appears, and what can the team detect and reverse without waiting for the vendor?
Test API and webhook evidence
Request the API version, environments, object model, authentication guide, rate limits, pagination, error schema, deprecation policy and change log. RFC 9110 (IETF, June 2022) defines HTTP status semantics; ask how the vendor distinguishes an accepted asynchronous write, a rejected request and a timeout where the write may have succeeded.
| Area | Evidence to request | Stop signal |
|---|---|---|
| API objects | Create, read, update, search, archive/delete; stable IDs; required fields; enums; nulls; dates and timezones | Required ATS object or field is unsupported |
| Limits | Rate, burst, quota, timeout, pagination and backoff guidance | Retry could overload the ATS or silently skip records |
| Webhook events | Event names, payloads, ordering, late/duplicate delivery, immutable event ID | No deduplication key or current schema |
| Authenticity | Signature, timestamp, replay protection and secret rotation | Receiver cannot verify origin |
| Delivery | Retry schedule, dead-letter/quarantine, logs, alert, replay and pause controls | Only vendor support can find or replay a failure |
| Change control | Versioning, notice period, sandbox event and compatibility policy | A breaking change can reach production without review |
If there is no webhook, compare polling freshness, rate cost, missed-change behavior and reconciliation. Test an unavailable ATS, 429 response, malformed field, invalid signature and network timeout with a harmless record.
Map data and access
Request a field-level map, not a screenshot. Include candidate and job IDs, source URL, approved contact fields, location, stage, owner, disposition, notes, timestamps, attachments and consent or other provenance records. Mark each field required, transformed, derived, unsupported or intentionally excluded. Test a duplicate, long note, unsupported attachment, renamed stage and changed identifier.
| Control | Buyer question | Evidence |
|---|---|---|
| Identity | What stable key prevents a duplicate or unsafe merge? | Match rule, conflict behavior and manual review result |
| Authentication | Is it OAuth, API key, service account or signed request? | Scope list, token storage, expiry, rotation and revocation test |
| Permissions | Can access be limited by workspace, object and role? | Recruiter, hiring-manager, admin and read-only tests |
| Audit | Who changed a field, credential, export or stage? | Searchable audit event with actor and timestamp |
| Correction | How are changes, deletion or restriction requests handled in both systems? | Owner, procedure and completion evidence |
RFC 6749 (IETF, October 2012) describes OAuth's delegated-access model; RFC 7636 (IETF, September 2015) describes proof-key protection for public clients. Treat them as reference standards, not proof of implementation. Prefer a dedicated, least-privilege integration identity over a recruiter's personal account.
Review privacy, security and support
Ask where candidate data, attachments, logs, backups and support copies are processed; how long each is retained; which subprocessors can access it; and how return, deletion, incidents and international transfers work. Do not put a real CV into a trial before the data owner approves the test data and destination.
Use NIST Cybersecurity Framework 2.0 (NIST, February 26, 2024) to structure evidence across Govern, Identify, Protect, Detect, Respond and Recover. Use the OWASP API Security Top 10, 2023 edition (released July 2023), to ask about authorization, authentication, resource limits, configuration and unsafe API consumption. Neither source is a vendor certification.
The EU GDPR is dated April 27, 2016; Article 25 addresses data protection by design and default. ICO UK GDPR guidance, updated February 5, 2026, describes considering privacy through the system lifecycle. These references do not decide which law applies. Ask the responsible owner to record the applicable rule, evidence, exception and decision date.
| Support and lifecycle question | Required answer |
|---|---|
| Who monitors delivery, rate limits, credentials and schema changes? | Named internal owner and vendor escalation route |
| What is the response path for data loss, duplicate writes or security incidents? | Severity definitions, acknowledgement, updates and recovery owner |
| What does support see? | Access approval, support logs, retention and subprocessor boundary |
| How is the integration disabled? | Pause, drain, revoke, fallback and resume procedure |
| How do we leave? | Export fields, attachments, audit history, fees, deletion and final confirmation |
Price implementation and rollback
Do not invent an integration price or assume a connector is included. Give every vendor the same scenario and request supplier cost for seats, jobs, candidates, attachments, API calls, events, environments, implementation, migration, support, monitoring, overages, tax, renewal and exit. Separate that quote from internal mapping, privacy review, testing, monitoring, repair and replacement effort. Record currency, assumptions, exclusions and quote date.
Before production writes, save the last-known-good field map, version, credential owner and sample export. Define whether rollback means pausing writes, reversing updates, restoring a record or manual correction; rollback is not automatically deletion. Accept only a design where an owner can determine whether a timeout wrote, quarantine a bad event and reconcile the ATS without duplicate candidates or overwritten decisions.
Score each dimension 0 (no evidence), 1 (partial or owner dependency) or 2 (documented and tested): workflow and fields; API/webhooks; identity and permissions; privacy/security; support and maintenance; supplier plus internal cost; export and exit. Decide PASS, PILOT WITH CONDITIONS or STOP.
Stop conditions
- Required fields, stages, attachments or provenance cannot be mapped and reconciled.
- Credentials are shared, over-privileged, unrotatable or impossible to revoke.
- Duplicate events, failed writes or invalid webhooks cannot be detected and recovered.
- Data locations, retention, subprocessors or support access remain unknown after review.
- Export is insufficient for correction, deletion or replacement.
- A required capability or billable unit is missing from the quote.
- No named owner can monitor, escalate and roll back the integration.
Copyable decision record
ATS INTEGRATION EVALUATION
Vendor, product, plan and quote date:
Integration path and source/receiving system:
Decision, technical, data and privacy owners:
Objects, fields, stages, attachments and provenance in scope:
API version, events, IDs, limits, retry and replay evidence:
Credential type, scopes, rotation, revocation and roles tested:
Data locations, retention, subprocessors, deletion and export:
Support route, monitoring owner and change policy:
Supplier cost, internal effort, overages and exit cost:
Failure tests and rollback result:
Score and decision: PASS / PILOT WITH CONDITIONS / STOP
Open condition, action, owner and due date:
Approval and next review date:Where Talent Summoner fits
Talent Summoner is our product, and its documented scope is candidate sourcing and candidate ranking, not an ATS integration. Candidate sourcing starts from a role brief and supports external discovery; candidate ranking reviews supplied CVs against a supplied role for human review. Neither page promises ATS API access, webhook delivery, applicant-pipeline management, automatic rejection, outreach or bidirectional synchronisation. Treat any manual export or link as a manual hand-off, with an owner and evidence, and review pricing only after that boundary is clear.
What should a small team test first?
Run one representative candidate from trigger to ATS record, including required fields, provenance, duplicate handling, a failed request and human verification.
Is a native connector automatically better than an API?
No. Compare field coverage, permissions, recovery, support, change control, exit and total operating effort against the same acceptance test.
How should we compare integration costs?
Use one scenario and written quotes. Separate seats, jobs, records, events, implementation, support, overages, renewal, internal effort and exit costs.
Does Talent Summoner integrate with an ATS?
Its current documented scope is sourcing and ranking. It is not an ATS and this checklist makes no API, webhook, connector or synchronisation claim.
When should we stop a pilot?
Stop for unmapped required data, unrecoverable writes, unsafe access, unresolved privacy or security risk, insufficient export, or no rollback owner.
Save the quote, field map, test evidence, failure logs and decision record together. Re-test after a material API, webhook, plan or schema change. For an approved role brief, start candidate sourcing; for existing CVs, use candidate ranking, then document the ATS hand-off separately.
