Workable-to-Greenhouse migration requires splitting flat candidate records into Candidate + Application objects, extracting resumes via API (no bulk download), and handling 10 req/10s rate limits on both sides.
There is no native migration path from Workable to Greenhouse; the two systems use fundamentally different data models. Workable treats candidates as flat, per-job records, while Greenhouse separates the person (Candidate) from the job candidacy (Application), requiring deduplication and re-mapping of every record. Resumes and attachments cannot be bulk-exported from Workable via CSV, necessitating API scripts or a full account data export, and Greenhouse's API enforces strict rate limits with base64-encoded file uploads for each attachment. Custom ETL work is required to translate pipeline stages, scorecards, and activity history between the two platforms.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Greenhouse Harvest API v1 and v2 will be deprecated and unavailable after August 31, 2026
Any new migration integration should target Harvest v3, which uses OAuth 2.0 instead of Basic Auth. If you're planning a migration in Q3 2026 or later, build directly against v3.
Do not map Workable's stage directly to a Greenhouse Candidate
Stages belong to the Application object in Greenhouse.
Greenhouse's bulk import has an auto-merge feature
If enabled, candidates added through bulk import are evaluated against existing profiles using configured match criteria (e.g., email address). Note that referral or specific agency sources are excluded from auto-merge even when they would otherwise match. Keep this in mind when planning import batches to avoid unintended merges or missed duplicates. (support.greenhouse.io)
If you need resumes, you must hit the individual candidate endpoint (/candidates/:id) for
If you need resumes, you must hit the individual candidate endpoint (/candidates/:id) for each record to get the resume URL, then download the file separately. That's two requests per candidate minimum — list + detail — which doubles your extraction time. Use OAuth tokens if available — they provide 5× the throughput.
Unlisted vendors on Greenhouse may be subject to additional rate limits beyond the standard 50/10s
If you're building a custom integration, register it in Greenhouse's Dev Center first to ensure you get the standard allocation.
If your internal worksheet uses CRM language, translate it before mapping
contact → candidate, lead → prospect or early-stage application, opportunity → application, activity → note, email, scorecard, or event. Neither Workable nor Greenhouse is a general-purpose CRM.
Keep three mapping tables
person_key → greenhouse_candidate_id, workable_candidate_id → greenhouse_application_id, and source_attachment_checksum → greenhouse_attachment_ref. That is what makes retries safe and idempotent.
Greenhouse support docs can conflict on some candidate upload limits and on which
Greenhouse support docs can conflict on some candidate upload limits and on which subscription tiers expose bulk import features. Test in a sandbox and get written confirmation from Greenhouse before you promise exact boundaries.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope candidates, pipelines and the compliance obligations that come with them.
Objective Agreed scope across candidates, applications, jobs and interview history, with legal signed up on retention.
Keep these open
-
Inventory every object in Workable
Count candidates, applications (a candidate can have many), jobs and requisitions, interviews, scorecards, offers, and resume files. Applications and scorecards usually outnumber candidates several times over, and resume files dominate storage.
Data Profiler Get real record counts instead of estimating from memory -
Settle retention and consent with legal
Candidate data is heavily regulated: GDPR right-to-erasure, EEOC/OFCCP record-keeping, and per-region retention windows that conflict with each other. Decide what may be migrated at all before you scope anything else — this frequently shrinks scope substantially.
Migrating candidate records whose consent has lapsed or whose retention window has expired creates a new compliance breach in the target system.
-
Map the hiring pipeline and agree the target stages
Document every job's pipeline, stage, and rejection reason, then agree the Greenhouse model with talent leadership. Stage definitions drive every funnel metric you report, so changing them silently rewrites your hiring analytics.
-
Catalogue integrations and the job-board estate
List job boards, careers-site integration, HRIS, background check, assessment platforms, calendar and email. The careers site and job boards are customer-facing, so their cutover needs its own plan and its own testing.
-
Build the business case and choose the window
Model licence delta, effort and recruiter productivity dip. Time the window against your hiring cycle: a migration during peak graduate recruitment or a hiring surge will fail on people, not technology.
Vendor Evaluator Score Greenhouse against alternatives on weighted criteria -
Record count comparison
total candidates created in Greenhouse vs. total extracted from Workable
-
Rebuild interview plans and scorecards
these don't migrate. Budget 1–2 weeks for configuration.
COI & ROI Calculator Build the 36-month business case you will need for sign-off
Workable → Greenhouse specifics
- Structured hiring enforcement
- Greenhouse's scorecard system, interview kits, and multi-stage approval workflows give talent operations teams consistent, auditable processes across departments and geographies. Greenhouse forces hiring managers to define scorecards and interview kits before a job goes live. Workable supports structured interviews but doesn't enforce scorecard completion or approval chains with the same rigor.
- Enterprise reporting and BI
- Greenhouse's Business Intelligence Connector delivers a nightly ETL of your recruiting data keyed on candidate_id, application_id, and job_id — a normalized schema purpose-built for warehouse integration into Snowflake or Redshift. Workable's reporting has improved but remains more limited for custom analytics.
- Integration ecosystem depth
- Greenhouse offers 500+ pre-built integrations and five distinct APIs (Harvest, Job Board, Ingestion, Assessment, Onboarding). For companies that need deep connections to HRIS, background check, and assessment platforms, Greenhouse's ecosystem is broader.
Don't move on until
- Counts confirmed for candidates, applications, jobs and offers
- Retention and consent obligations confirmed with legal
- Hiring-stage model agreed with talent leadership
02 Data Audit Audit candidate data with compliance sitting next to you.
Objective Profiled exports with duplicates, expired records and resume files all quantified and triaged.
Keep these open
-
Export and profile candidates, applications and jobs
Profile each object separately and reconcile against API counts. Watch the candidate-to-application ratio: a mismatch usually means applications have been silently truncated by pagination.
Data Profiler Profile the Workable export for nulls, outliers and type drift -
Quantify duplicate candidates and agree survivorship
The same person applies repeatedly over years with different emails and name spellings. Measure the duplicate rate and agree survivorship rules — which record wins and what happens to the application history attached to the losers.
Merging candidates without agreed survivorship rules destroys application and interview history that you may be legally required to retain.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Identify records outside their retention window
Flag candidates whose consent has expired, who have exercised erasure, or who fall outside regional retention. Exclude them from scope and document the exclusion — you need to show the decision was deliberate.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Inventory resume files and attachments
Count files, total volume and MIME types, and check every attachment still resolves to a live URL. Expiring signed download URLs are the classic reason a resume migration completes with a large fraction of empty files.
Resume download URLs are often short-lived signed links. Fetch files close to load time or they will 404 mid-migration.
-
Verify relationship integrity
Confirm every application links to a live candidate and a live job, and every scorecard to a real interview. Orphaned applications produce a funnel report that does not tie to anything.
-
Clean, normalise and produce masked test data
Normalise emails, phone formats and locations, standardise timestamps to UTC, and generate a masked dataset for the sandbox. Real candidate data in a sandbox is a compliance breach in most jurisdictions.
PII Masker Generate a safe copy for sandbox and vendor testing -
Download resume files
from the URLs in the response — do this immediately. Workable's resume download URLs are time-limited and will expire if you defer.
-
Pull activities
via /candidates/{id}/activities for comments, ratings, and events
Workable → Greenhouse specifics
- List all jobs
- via GET /spi/v3/jobs (paginate with limit=100)
- For each job
- , fetch candidates via GET /spi/v3/jobs/{shortcode}/candidates
- For each candidate
- , fetch detail via GET /spi/v3/candidates/{id} — the collection endpoint omits verbose fields like cover_letter, answers, resume_url, tags, and social profiles (workable.readme.io)
- Fetch custom attributes
- via GET /spi/v3/jobs/{shortcode}/custom_attributes
Don't move on until
- Duplicate candidate rate quantified with a merge policy agreed
- Records outside retention identified and excluded
- Resume and attachment inventory complete with total volume
03 Field Mapping Map the candidate-application-job triangle before anything else.
Objective A signed mapping covering objects, stages, rejection reasons, scorecards and EEO fields.
Keep these open
-
Map the candidate, application and job model
ATS platforms differ on whether a person or an application is the primary record. Establish this first: getting it wrong means one candidate becomes five, or five applications collapse into one, and the entire field map has to be redone.
Candidate-centric and application-centric models are not interchangeable. Confirm which Greenhouse uses before mapping any field.
Schema Mapper Opens pre-loaded with the Workable → Greenhouse field pair -
Map pipeline stages and rejection reasons exhaustively
Enumerate every stage and rejection reason across all jobs, including retired values on historical applications, and map each explicitly. Unmapped rejection reasons are both a reporting gap and, in regulated hiring, a compliance one.
-
Decide EEO and diversity data handling
These fields are separately regulated and often legally required to be stored apart from the candidate record. Confirm with legal whether they migrate at all, and how Greenhouse isolates them.
EEO data usually cannot be migrated into ordinary custom fields without breaching the segregation rules that govern it.
-
Map interviews, scorecards and feedback
Structured scorecards rarely have a native equivalent. Decide whether to reconstruct them, flatten them into notes, or keep them only in the archive — and be explicit that flattening loses the ability to report on them.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Plan resume and file migration
Confirm size limits, MIME support and whether Greenhouse re-parses resumes on upload. Re-parsing can overwrite carefully curated candidate fields with worse machine-extracted values, so test it deliberately.
-
Set load order and freeze the spec
Users, then jobs, then candidates, then applications, then interviews and scorecards, then files. Keep source IDs in custom fields, then version and sign off the spec.
-
Deduplicate candidates by email
group all Workable records for the same email into one Candidate record
-
Map fields
rename and reformat per the mapping tables above
Data Format Converter Reshape the export into the format Greenhouse's importer expects -
Resolve source IDs
match Workable source strings to Greenhouse source IDs
Workable → Greenhouse specifics
- Multi-select values
- use the correct option IDs, not display names
Don't move on until
- Candidate/application/job model mapped and reviewed
- Every stage and rejection reason explicitly mapped
- EEO and diversity field handling agreed with legal
04 Test Migration Pilot whole candidate journeys, not isolated records.
Objective A sandbox pilot where candidate journeys, funnel metrics and resume files all verify.
Keep these open
-
Configure the Greenhouse sandbox with the agreed pipelines
Create jobs, pipeline stages, scorecard templates, user roles and custom fields first. Loading applications before the stages exist puts every candidate in a default stage and invalidates the pilot.
-
Select complete candidate journeys as the pilot slice
Take 100-200 candidates with all their applications, interviews, scorecards and files — including repeat applicants, hires, rejections at every stage, and candidates on multiple jobs. Repeat applicants are where the model mapping actually gets tested.
-
Run the load in dependency order with logging
Jobs, candidates, applications, interviews, then files, logging each request against its source ID. Track file uploads separately: they fail for different reasons and at different rates than record writes.
-
Verify journeys and funnel metrics
Confirm each candidate sits at the right stage on the right job with their history intact, and that per-stage funnel counts match Workable for the pilot jobs. Funnel mismatches point straight back to stage mapping.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Open every pilot resume and check re-parsing
Actually open the files rather than trusting the upload count, and check whether re-parsing has overwritten any candidate fields. A resume that uploaded as a zero-byte file still counts as a success in most logs.
-
Put recruiters in front of the pilot data
Have recruiters work their own pilot requisitions end to end. They immediately spot missing feedback, wrong stages and unreadable history that reconciliation cannot see.
-
Test auto-merge behavior
import a known duplicate and confirm Greenhouse handles it per your configuration
-
Load test your script
run against the full dataset in a Greenhouse sandbox before production
Don't move on until
- Candidate-application-job relationships intact for the pilot
- Funnel counts per stage match source for pilot jobs
- Resume files open correctly for every pilot candidate
05 Cutover Switch recruiting without dropping a live candidate.
Objective All in-scope recruiting data live in Greenhouse, careers site and boards repointed, recruiters working.
Keep these open
-
Pre-load historical candidates and closed jobs
Load closed requisitions, rejected candidates and archived applications while Workable stays live. Only active pipeline and the final delta need to move in the window.
-
Publish the runbook including the careers-site switch
A timed sequence with owners and abort criteria, treating the careers site and job boards as first-class steps. They are candidate-facing, so a failure there is publicly visible in a way a data defect is not.
-
Freeze Workable and take the final delta
Stop new applications and let recruiters finish in-flight actions, then export everything changed since the pre-load. Coordinate with anyone actively interviewing so feedback is not entered into the old system mid-freeze.
Interview feedback entered in the old ATS during the freeze is lost, and it is the data recruiters most immediately notice missing.
-
Load active pipeline and reconcile stages
Load active candidates and applications, then verify every active candidate is at the correct stage on the correct job before repointing anything. Active-stage accuracy is what recruiters check first on day one.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint careers site, job boards and integrations
Switch the careers-site integration, repost or migrate live job ads, and repoint HRIS, background check, assessment and calendar integrations. Then submit a real test application through the careers site and every major board.
Job ads left posted against the old ATS keep collecting applications that never reach the new system.
-
Go/no-go and switch recruiters over
Call the decision against the exit criteria, then move recruiters with support on hand for the first day. Keep Workable read-only — candidate records have retention obligations that outlast the migration.
Workable → Greenhouse specifics
- Before import
- Take a full export of your Greenhouse instance (if you have existing data)
- During import
- Track every created record ID. If the migration fails, use DELETE endpoints to remove imported records (requires appropriate API permissions)
- Tag everything
- Mark all migrated records with a date-stamped tag (e.g., workable-migration-2026-04-21). This makes cleanup possible if needed.
Don't move on until
- Historical load complete and reconciled before the freeze
- Careers site and job boards posting into Greenhouse and verified
- Active candidates confirmed at the correct stage
06 Validation Prove the funnel, the files and the compliance position.
Objective Reconciled recruiting data, funnel parity with baseline, and a defensible compliance record.
Keep these open
-
Reconcile every object including files
Compare counts for candidates, applications, jobs, interviews, scorecards and files, with field-level spot checks on a sample. Count files separately — they are the object most likely to be quietly short.
Migration Validation Tool Reconcile Workable and Greenhouse record-for-record -
Tie funnel and time-to-hire reporting to baseline
Rebuild funnel conversion, time-to-hire, source effectiveness and offer-acceptance reporting and compare to pre-migration figures. Variances trace back to stage mapping and to how application timestamps were handled.
Time-to-hire depends on stage-transition timestamps. If those were approximated, the metric will differ even with identical records.
-
Verify file integrity at scale
Sample-open resumes across the whole load and compare file sizes against source. Zero-byte and truncated files are common and never surface in an upload success count.
-
Confirm retention, consent and EEO configuration
Verify retention rules, consent state and EEO segregation are correctly configured in Greenhouse, and that excluded records genuinely did not migrate. File this as your compliance evidence.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test workflow, notifications and candidate-facing paths
Fire every stage automation, interview scheduling flow, rejection template and offer approval, and submit a live application through the careers site. Candidate-facing emails going out wrong is a brand problem, not just a bug.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, retain Workable read-only for the period your retention policy requires, take a final archive export, and diarise cancellation.
-
Verify in Greenhouse UI
check that profiles render correctly, resumes open, custom fields display
Data Profiler Prove field completeness held up through the load -
Validate GDPR behavior
confirm consent emails are suppressed during import if intended
-
Configure job board integrations
Greenhouse connects to job boards differently than Workable.
Workable → Greenhouse specifics
- Field-level sampling
- pick 50+ random candidates, compare every field value
- Resume spot check
- open 20 candidate profiles in Greenhouse UI, verify resumes are downloadable
- Relationship check
- verify multi-application candidates show all applications under one profile
- Recreate email templates
- Greenhouse email templates are separate from Workable's.
- Train recruiters and hiring managers
- users coming from Workable need orientation on scorecards, approvals, and the Candidate vs. Application distinction.
Don't move on until
- Reconciliation complete across candidates, applications and files
- Funnel and time-to-hire reporting tie to baseline
- Retention and EEO configuration verified, acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Object Equivalent
| Workable field | Greenhouse field | Notes |
|---|---|---|
| Job | Job | Map Workable shortcode to Greenhouse job_id |
| Candidate (per job) | Candidate + Application | Deduplicate by email → one Candidate, one Application per job |
| Pipeline Stage | Interview Plan Stage | Map stage names; Greenhouse uses milestones (Application, Assessment, Face to Face, Offer) |
| Tags | Candidate Tags | Direct 1:1 mapping |
| Source | Source | Map Workable source names to Greenhouse source IDs |
| Comments / Notes | Notes (on Application) | Preserve author and timestamp in note body |
| Resume | Attachment (type: resume) | Download from Workable, base64-encode, POST to Greenhouse |
| Cover Letter | Attachment (type: cover_letter) | Same flow as resume |
| Evaluations / Ratings | Notes or Scorecards | Greenhouse scorecards are tied to specific interview stages — Workable evaluations usually become notes |
| Custom Fields | Custom Candidate/Application Fields | Type-aware mapping required; see below |
| Hiring Team | Job Hiring Team | Map recruiter/coordinator to Greenhouse user IDs |
| Offer | Offer object | Custom offer fields may have dependencies |
Workable Greenhouse
| Workable field | Greenhouse field | Notes |
|---|---|---|
| name | first_name + last_name | Split on first space |
| email_addresses [0].value | Primary dedup key | |
| phone | phone_numbers [0].value | |
| headline | title | |
| address | addresses [0].value | |
| summary | Note body | No direct Candidate field |
| education_entries | educations | Map school, degree, field |
| experience_entries | N/A (notes or custom) | No structured work history field in Greenhouse |
| tags | tags | |
| source | source.id | Map to Greenhouse source IDs |
| stage | current_stage.id | Map to interview plan stage — do not map by label similarity alone |
| disqualified | rejected_at + rejection_reason | |
| resume_url | Attachment (type: resume) | Download → base64 → POST |
| cover_letter_url | Attachment (type: cover_letter) | Same flow |
| answers (custom questions) | Custom application fields | Type-aware mapping |
| custom_attributes | Custom candidate fields | Validate picklist values |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Candidate Records | medium | Candidates must be deduplicated by email across multiple Workable job records and consolidated into single Greenhouse Candidate objects, with risk of missed duplicates or unintended merges from Greenhouse's auto-merge feature. |
| Applications | medium | Each Workable per-job candidate record must be re-created as a separate Greenhouse Application linked to the correct Candidate and Job, requiring careful relational mapping that has no direct CSV equivalent. |
| Resumes and Attachments | high | Workable does not support bulk resume downloads natively, and Greenhouse's bulk import can silently drop resumes if email parsing fails to match the file to a candidate row. |
| Pipeline Stages | medium | Stages belong to different objects in each system (candidate in Workable vs. application in Greenhouse), and historical candidates cannot be placed into accurate pipeline stages without container-job workarounds. |
| Scorecards and Evaluations | high | Workable evaluations do not map to Greenhouse's scorecard-per-application-per-interview model, and CSV-based migration methods lose this data entirely. |
| Interview Feedback and Activity History | high | Detailed activity timelines, comments, and interview feedback are lost in CSV exports, and interviews cannot be backdated in Greenhouse even though scorecards can. |
| Custom Fields | medium | Greenhouse bulk import only supports simple custom field types (short text, number, single select, URL, Yes/No), so complex custom fields require API-based migration. |
| Jobs and Job Structures | low | Job records are relatively straightforward to recreate in Greenhouse, though interview plans, approval workflows, and scorecard templates must be manually configured. |
| Sources and Tags | low | Candidate sources and tags export cleanly from Workable's CSV and API and can be mapped to Greenhouse's source and tag fields with minimal transformation. |
| GDPR/CCPA Compliance Data | medium | Candidate consent records and data retention policies may not transfer cleanly between platforms, requiring manual verification to maintain compliance during the migration. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Candidate-to-Application Model Translation
Workable stores candidates as flat per-job records, requiring deduplication by email and remapping into Greenhouse's separate Candidate and Application objects to preserve multi-job candidacy relationships.
Bulk Resume Extraction Bottleneck
Workable's CSV export excludes resume files entirely, forcing teams to use individual API calls per candidate or request a full account data export that requires archiving all active jobs.
API Rate Limit Constraints
Workable's account-token rate limit of 10 requests per 10 seconds and Greenhouse's own API throttling make large-scale migrations (10,000+ candidates) take hours of continuous API calls with careful backoff logic.
Scorecard and Activity History Loss
Workable evaluations and interview feedback do not map directly to Greenhouse's scorecard-per-application-per-interview structure, and CSV bulk import drops this data entirely.
Pipeline Stage Mapping Complexity
Workable stages are properties of the candidate record, while Greenhouse stages belong to the Application object within a job's interview plan, requiring careful per-job stage alignment and historical candidate workarounds.
Greenhouse API Version Deprecation
Greenhouse Harvest API v1 and v2 will be deprecated after August 31, 2026, meaning any new migration integration must target v3 with OAuth 2.0 authentication instead of Basic Auth.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
Duplicate records across jobs
The same person applied to 5 jobs in Workable → 5 separate records. If you don't deduplicate before import, Greenhouse's auto-merge may or may not catch them depending on your configuration. If auto-merge is disabled, you'll have 5 separate Candidate profiles.
Candidates without email addresses
Greenhouse uses email as the primary match key for auto-merge. Sourced candidates in Workable sometimes lack emails. These will create orphan records that can't be merged later.
Resume URLs that expire
Workable's API returns resume download URLs that are time-limited. If you extract candidate data one day and download resumes a week later, the URLs may have expired. Download files immediately after extraction.
Custom field data type mismatches
A "number" field in Workable containing the string "$75,000" will fail Greenhouse's number validation. Clean these during the transform phase.
Scorecard data
Workable evaluations don't map 1:1 to Greenhouse scorecards, which are tied to specific interview stages in a job's interview plan. You'll likely need to import these as notes rather than structured scorecards.
GDPR consent auto-emails
When importing candidates into Greenhouse jobs configured for GDPR compliance, Greenhouse automatically emails consent requests to imported candidates. Disable this during bulk imports or use the container job method. (support.greenhouse.io)
Large attachment payloads
Base64-encoding a 10 MB resume inflates it to ~13.3 MB. The Greenhouse API may reject very large payloads. Check content size before upload and consider URL-based attachment upload for large files.
Orphaned activities
If a user account was deleted in Workable, their historical notes and scorecards might fail to attach in Greenhouse. Map deleted users to a generic "System Admin" account to preserve the audit trail.
Resume matching failures in bulk import
Greenhouse can fail to attach resumes during bulk import if it cannot parse the file, cannot find an email, or finds an email that doesn't match the imported candidate row. (support.greenhouse.io)
Private field access
Greenhouse bulk import visibility for private custom fields depends on the importing user's permissions on all jobs in scope. (support.greenhouse.io)
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I export resumes from Workable in bulk?
No. Workable's Candidate Details CSV excludes resumes and files. You can either request a full account data export from Workable support (which requires archiving all jobs and is all-or-nothing) or use the Workable API to download resumes individually from URLs in candidate detail responses. ([help.workable.com](https://help.workable.com/hc/en-us/articles/115014887828-How-do-I-export-candidate-data))
What are the Workable API rate limits for data extraction?
Workable limits account tokens to 10 requests per 10 seconds and OAuth/Partner tokens to 50 requests per 10 seconds. Exceeding these returns HTTP 429. Monitor the X-Rate-Limit-Remaining header and pause before hitting zero. ([help.workable.com](https://help.workable.com/hc/en-us/articles/4903195036183-Troubleshooting-API-issues))
How does Greenhouse's data model differ from Workable's?
Workable associates candidates directly with jobs as flat records. Greenhouse separates Candidates (the person) from Applications (the candidacy for a specific job). One Candidate can have multiple Applications. You must deduplicate Workable records by email and create one Candidate per person with separate Applications per job. ([support.greenhouse.io](https://support.greenhouse.io/hc/en-us/articles/360001905032-Business-Intelligence-Connector-data-model))
Is Greenhouse Harvest API v1 being deprecated?
Yes. Harvest API v1 and v2 will be deprecated and unavailable after August 31, 2026. All new integrations should use Harvest v3, which requires OAuth 2.0 authentication instead of Basic Auth and uses a 30-second fixed-window rate limit.
How many candidates can I bulk import into Greenhouse at once?
Greenhouse recommends a maximum of 8,000 candidates per bulk import batch. The resume .zip file has a 5 GB size limit. The bulk import tool is only available on Plus and Pro subscription tiers. For larger datasets, split into multiple imports or use the Harvest API. ([support.greenhouse.io](https://support.greenhouse.io/hc/en-us/articles/38329467264027-Adding-historical-candidates-to-Greenhouse-using-bulk-import))