--- title: "ATS API and webhooks for developers: Integration guide" description: "Learn how ATS APIs and webhooks work, which recruiting records and events to integrate, and how to handle authentication, retries, security, testing, and monitoring." canonical: "https://recooty.com/resources/blogs/ats-api-and-webhooks-for-developers" author: "Recooty Team" date: "2026-09-15T00:00:00+05:30" updated: "2026-09-15T00:00:00+05:30" image: "https://recooty.com/resources/blogs/media/2026/09/23-ats-api-and-webhooks-for-developers-facb2d0391fa.png" --- # ATS API and webhooks for developers: Integration guide An ATS API lets software read or change recruiting data through defined requests. Teams comparing [recruiting software](https://recooty.com/) can use this overview to assess which workflow fits their hiring process. ATS webhooks send an event notification when something changes, such as a candidate being hired. Most reliable integrations use webhooks to detect events and the API to fetch, validate, or update the related record. I design these integrations around ownership and failure recovery first. Moving a candidate record is easy; keeping two systems accurate after retries, edits, duplicates, and outages takes more care. ## Key takeaways - APIs are request based, while webhooks push event notifications. - Define the system of record for jobs, candidates, applications, and employees. - Use stable identifiers and idempotent processing to prevent duplicates. - Verify webhook signatures and retrieve current record data before acting. - Log technical context without exposing unnecessary candidate information. - Test retries, out-of-order events, deleted records, expired credentials, and rate limits. ## What is an ATS API? An [applicant tracking system](https://recooty.com/applicant-tracking-system) API is a documented interface for accessing jobs, candidates, applications, stages, interviews, offers, users, or reports programmatically. Available objects and actions depend on the vendor and plan. Typical API use cases include: - Create or update jobs from a workforce planning system - Add sourced candidates from an approved internal tool - Read application status for a hiring dashboard - Send assessment results back to the correct application - Create onboarding records after an accepted offer - Synchronize users, departments, locations, and job codes - Export recruiting data to an analytics warehouse - Process candidate data correction or deletion workflows The API documentation should define authentication, endpoints, field types, pagination, filtering, rate limits, errors, versioning, and data permissions. ## What is an ATS webhook? An ATS webhook is an HTTP request sent to a registered endpoint after a defined event. It can tell another system that a candidate was created, an application changed stage, an interview was scheduled, an offer was accepted, or a job closed. Use an [interview question generator](https://recooty.com/tools/interview-question-generator/) to prepare role-specific questions before the conversation. A webhook payload may be small: ```json { "event_id": "evt_01842", "event_type": "application.hired", "occurred_at": "2026-09-15T09:30:00Z", "application_id": "app_72391", "candidate_id": "cand_48120" } ``` I prefer a small event with stable identifiers. The receiver can acknowledge quickly and use the API to retrieve the latest authorized record. ## API vs webhook: Which should you use? Use webhooks for timely event detection and APIs for record operations. Polling an API can work when no webhook exists, but it adds delay, repeated requests, and state-tracking work. | Need | API | Webhook | | ---------------------------------- | ------------------ | ----------------------- | | Read current candidate or job data | Yes | Payload may be limited | | Create or update a record | Yes | Usually no | | Learn about a change quickly | Polling required | Yes | | Recover after missed events | Query current data | Replay may be available | | Run scheduled warehouse sync | Yes | Can complement it | The integration can receive `application.hired`, place the event in a queue, retrieve the application and accepted job, validate required fields, then create the onboarding record. ## Which ATS records need clear ownership? Choose one authoritative owner for each field and lifecycle stage. Bidirectional sync without field ownership can overwrite corrections and create loops. | Record | Likely source before hire | Likely destination or consumer | | ------------------------------------------------------------------------------------------------------------------------- | ------------------------- | ------------------------------------------------------------------------------- | | Requisition | Workforce planning or ATS | ATS | | Job posting | ATS | [Careers page](https://recooty.com/features/company-career-page) and job boards | | Candidate profile | ATS | Approved recruiting tools | | Application stage | ATS | Dashboards and notifications | | Assessment result | Assessment platform | ATS | | Accepted hire | ATS | Onboarding or HRIS | | Employee identifier | HRIS | ATS reference where needed | | When the role is ready, you can [post a job for free](https://recooty.com/free-job-posting) to start reaching candidates. | | | Use vendor IDs as external references, not user-facing names or email alone. A person can apply several times and may change contact information. ## How should webhook processing work? The endpoint should authenticate the event, acknowledge it quickly, and process business logic asynchronously. This reduces vendor timeouts and gives your service room to retry safely. 1. Receive the webhook over HTTPS. 2. Verify its signature, timestamp, and expected source. 3. Check if the event ID was processed already. 4. Store minimal event metadata in a durable queue. 5. Return the expected success response promptly. 6. Fetch current record data from the API if needed. 7. Validate the event against current status and business rules. 8. Apply an idempotent create or update. 9. Record success or a readable error. 10. Retry transient failures and route permanent failures for review. Assume delivery can happen more than once and out of order. A delayed interview event should not overwrite a later hired status. ## How do you prevent duplicate hires or candidates? Use an idempotency key tied to the source record and operation. Store the ATS application ID beside the destination onboarding or employee record, then update that record on retry. Email addresses are useful matching signals but weak primary identifiers. Shared mailboxes, changed addresses, and duplicate profiles can create false matches. For manual merges, retain an alias or redirect from old IDs if the API provides one. Test what webhooks do after records merge. ## How should authentication and candidate data be secured? Use the vendor's supported OAuth, scoped token, or service-account method. Grant only the records and actions the integration needs, store credentials in a secret manager, and rotate them under a documented process. Security review should cover: - TLS and webhook signature verification - Token scope, storage, rotation, and revocation - Separate test and production credentials - Personal data in payloads and logs - Encryption and retention for queued events - Access to retry and administration tools - Vendor and internal audit history - Incident response and kill switch Do not log full resumes, interview notes, or tokens. Use record IDs and sanitized error details when they are enough for support. ## How do you handle rate limits and pagination? Read headers and documentation for request limits, reset windows, cursor behavior, and retry guidance. Apply exponential backoff with jitter for supported transient errors and honor `Retry-After` when provided. For pagination, store the cursor only after a page is processed successfully. Use an updated-since filter for incremental synchronization, while planning a periodic reconciliation that finds missed or changed records. ## What should an ATS integration test plan include? Test contract behavior and recruiting meaning. A request returning HTTP 200 does not prove that the correct candidate, job, or field reached the destination. Include: - Valid create and update - Missing required fields - Unknown enum values - Duplicate event delivery - Events arriving out of order - Pagination during concurrent changes - Rate limiting and vendor downtime - Expired or revoked credentials - Candidate merge and deletion - Rehire and internal candidate - Hire withdrawal after transfer - Schema or API version change - Reconciliation between systems Monitor event age, success rate, retries, dead-letter count, authorization failures, and reconciliation differences. Alerts need an owner who understands the hiring consequence. Recooty has more than 100 third-party integrations. Developers evaluating a custom connection should confirm current API access, webhook events, authentication, limits, supported objects, and plan requirements directly with Recooty. The [ATS migration guide](https://recooty.com/resources/blogs/migrating-from-legacy-ats-to-recooty-avoid-pitfalls) can help with source-data preparation. ## Frequently asked questions about ATS APIs ### Does every ATS have an API? No. API availability, endpoints, write access, and support may depend on vendor and plan. Some systems provide native integrations or exports without a public API. Request current documentation and test access before signing a contract that depends on custom development. ### Are ATS webhooks reliable? Webhooks can be reliable when the sender retries and the receiver verifies, queues, deduplicates, monitors, and reconciles events. Network failures and duplicate delivery should be expected. Build for at-least-once delivery unless the vendor documents another guarantee. ### Should an integration store ATS data? Store only what the integration needs for processing, idempotency, support, and approved downstream use. Set retention and access according to the sensitivity and business purpose. Avoid copying full candidate records into integration logs or temporary databases without a defined need. ### How do you test an ATS webhook locally? Use the vendor's sandbox and webhook replay tools if available, plus a controlled HTTPS development endpoint. Validate signatures exactly as production will. Use synthetic candidate data and test duplicate, delayed, invalid, and retried events before handling real records. ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Article", "headline": "ATS API and webhooks for developers: Integration guide", "description": "APIs are request based, while webhooks push event notifications. Define the system of record for jobs, candidates, applications, and employees. Use stable identifiers and idempotent processing to prevent duplicates. Verify webhook signatures and retrieve current record data before acting. Log technical context without exposing unnecessary candidate information. Test retries, out-of-order events, deleted records, expired credentials, and rate limits.", "inLanguage": "en", "author": { "@type": "Organization", "@id": "https://recooty.com/#organization", "name": "Recooty" }, "publisher": { "@type": "Organization", "@id": "https://recooty.com/#organization", "name": "Recooty", "url": "https://recooty.com/", "logo": { "@type": "ImageObject", "url": "https://recooty.com/wp-content/uploads/2020/10/recooty-logo.png" } }, "datePublished": "2026-09-15", "dateModified": "2026-09-15", "@id": "https://recooty.com/resources/blog/ats-api-and-webhooks-for-developers#article", "url": "https://recooty.com/resources/blog/ats-api-and-webhooks-for-developers", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://recooty.com/resources/blog/ats-api-and-webhooks-for-developers#webpage" } }, { "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does every ATS have an API?", "acceptedAnswer": { "@type": "Answer", "text": "No. API availability, endpoints, write access, and support may depend on vendor and plan. Some systems provide native integrations or exports without a public API." } }, { "@type": "Question", "name": "Are ATS webhooks reliable?", "acceptedAnswer": { "@type": "Answer", "text": "Webhooks can be reliable when the sender retries and the receiver verifies, queues, deduplicates, monitors, and reconciles events. Network failures and duplicate delivery should be expected." } }, { "@type": "Question", "name": "Should an integration store ATS data?", "acceptedAnswer": { "@type": "Answer", "text": "Store only what the integration needs for processing, idempotency, support, and approved downstream use. Set retention and access according to the sensitivity and business purpose." } }, { "@type": "Question", "name": "How do you test an ATS webhook locally?", "acceptedAnswer": { "@type": "Answer", "text": "Use the vendor's sandbox and webhook replay tools if available, plus a controlled HTTPS development endpoint. Validate signatures exactly as production will." } } ], "@id": "https://recooty.com/resources/blog/ats-api-and-webhooks-for-developers#faq" } ] } ```