ATS Integration Evaluation Checklist

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.

We build Talent Summoner, a sourcing and ranking product, not an ATS; your first Role is free with no card. The checklist below applies to any ATS integration you evaluate.

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 or bidirectional synchronisation. 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.