feat(ashby): add 15 new tools and fix existing tool accuracy

[waleedlatif1]

Summary

• Added 15 new Ashby tools: list_interviews, list_departments, list_locations, list_sources, list_candidate_tags, list_archive_reasons, list_custom_fields, list_users, list_openings, list_job_postings, get_job_posting, get_offer, add_candidate_tag, remove_candidate_tag, change_application_stage
• Fixed create_application and create_note responses to match actual API (only return IDs, not full objects)
• Fixed create_candidate and update_candidate to use flat field format instead of nested objects
• Fixed list_applications createdAfter to convert ISO string to epoch milliseconds
• Fixed list_locations address nesting (postalAddress wrapper)
• Fixed list_interviews interviewPlanId → interviewStageId
• Updated block definition with all new operations, subBlocks, and conditions

Type of Change

• New feature
• Bug fix

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 19, 2026 5:02am

[cursor]

PR Summary

Medium Risk
Adds many new Ashby API integrations and changes request/response shapes for existing tools, which may break downstream workflows expecting prior payloads. Risk is moderate because changes are localized to the Ashby connector but affect multiple operations and outputs.

Overview
Ashby integration is significantly expanded and corrected. The Ashby block now exposes additional operations (tags, change application stage, offers/job postings, interviews, and multiple reference-data list endpoints) with new required inputs and outputs, and the tool registry exports/registers these new tools.

Existing tool contracts are adjusted for API accuracy.create_application and create_note now return only IDs, candidate create/update requests switch to a flatter payload shape (and require email on create), get_candidate/get_job send id (trimmed) instead of candidateId/jobId, list_applications converts createdAfter to epoch ms, list_offers output is reshaped to latest-version fields, and search_candidates includes createdAt/updatedAt.

^{Written by Cursor Bugbot for commit 8221d3f. Configure here.}

[greptile-apps]

Greptile Summary

This PR significantly expands the Ashby integration from ~10 tools to 25, adding 15 new tools covering reference data, job postings, offers, interviews, and candidate tag management, while also fixing several pre-existing API shape mismatches. The new tools are well-structured and follow consistent codebase patterns.

Key changes and concerns:

• create_application.ts — applicationId still always null: The PR changed the output to applicationId: r.applicationId ?? null, but r = data.results is an application object whose own ID lives at r.id (not r.applicationId). This field will always resolve to null, making the create_application tool's output useless for downstream steps.

• create_candidate.ts and update_candidate.ts — flat field migration: Both tools were refactored from nested primaryEmailAddress/primaryPhoneNumber/socialLinks objects to flat email, phoneNumber, linkedInUrl, githubUrl, websiteUrl fields. This is a breaking API shape change for existing workflows. The author indicates this was manually tested against the Ashby API.

• list_applications.ts — silent NaN date filter: new Date(invalidString).getTime() returns NaN, which JSON.stringify converts to null. An invalid createdAfter value silently drops the filter instead of surfacing a validation error.

• subblock-migrations.ts: Old emailType and phoneType sub-block IDs are renamed to _removed_emailType/_removed_phoneType rather than deleted. These orphaned entries are not present in the current block definition, so the executor safely ignores them. The approach is unconventional but functionally correct.

• create_note.ts — output simplified from a full note object to just noteId. This is a breaking change for any workflow that references output.content, output.author, or output.createdAt from a create_note step.

• ashby.ts block — interviewStageId field for create_application was removed from mode: 'advanced', making it always visible in the UI. This adds UI noise for the common case where users create applications on the default stage.

• All 15 new tools (list_sources, list_candidate_tags, list_archive_reasons, list_custom_fields, list_departments, list_locations, list_job_postings, get_job_posting, list_openings, list_users, list_interviews, get_offer, add_candidate_tag, remove_candidate_tag, change_application_stage) are correctly wired into index.ts, registry.ts, and the block's access list with consistent tool IDs.

Confidence Score: 3/5

• Merge with caution — one known unresolved data bug in create_application and two silent failure modes remain.
• The 15 new tools are cleanly implemented and consistent with codebase patterns. However, the create_application tool's output applicationId will always be null (uses r.applicationId instead of r.id), the create_note/create_application output shape changes are breaking for existing workflows, and list_applications.createdAfter silently drops invalid dates. The flat-field migration for create_candidate/update_candidate is a significant behavioral change that relies solely on manual testing.
• apps/sim/tools/ashby/create_application.ts (applicationId always null), apps/sim/tools/ashby/list_applications.ts (silent NaN date), apps/sim/tools/ashby/create_note.ts (breaking output shape change)

Important Files Changed

Filename	Overview
apps/sim/tools/ashby/create_application.ts	Response output applicationId uses r.applicationId instead of r.id — the field will always be null since the Ashby application object exposes its ID at r.id, not r.applicationId. This known issue was flagged in previous thread and remains unaddressed.
apps/sim/lib/workflows/migrations/subblock-migrations.ts	Maps old emailType/phoneType sub-block IDs to _removed_emailType/_removed_phoneType. These orphaned entries are not in the block definition, so the executor safely ignores them. The approach is unconventional (rename rather than delete) but functionally correct given the migration engine's design.
apps/sim/tools/ashby/list_applications.ts	Correctly converts createdAfter ISO string to epoch ms. However, an invalid ISO string produces NaN which JSON-serialises to null, silently dropping the filter. Input validation before conversion would surface clearer errors to users.
apps/sim/tools/ashby/create_candidate.ts	Refactored to flat field format (email, phoneNumber, linkedInUrl, githubUrl) matching the Ashby API. Email is now required. websiteUrl is still absent from the request body while the block UI shows the field for create_candidate — silently ignored, though this was pre-existing behavior.
apps/sim/tools/ashby/update_candidate.ts	Correctly migrated to flat field format. websiteUrl now correctly sent as body.websiteUrl (not the previous body.website), and nested primaryEmailAddress/primaryPhoneNumber structures are replaced with flat email/phoneNumber fields.
apps/sim/blocks/blocks/ashby.ts	Correctly expanded with 15 new operations, updated conditions, and new subBlocks for tagId, offerId, jobPostingId, and archiveReasonId. The interviewStageId field lost its mode: 'advanced' for create_application making it always visible — a minor UX concern from previous threads that remains unaddressed.
apps/sim/tools/ashby/list_interviews.ts	New ashby_list_interviews tool correctly uses interviewSchedule.list, maps interviewStageId filter and pagination, and returns properly shaped interview schedule objects. interviewStageId is now visible in the block UI per previous thread fix.
apps/sim/tools/ashby/get_offer.ts	New ashby_get_offer tool correctly reads offer details via offer.info, extracting top-level fields (id, offerStatus, acceptanceStatus, applicationId) and version-specific fields (startDate, salary, openingId, createdAt) from latestVersion.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A([Ashby Block]) --> B{operation}
B --> C[Candidate Operations]
B --> D[Application Operations]
B --> E[Job / Posting Operations]
B --> F[Offer Operations]
B --> G[Reference Data]
B --> H[Interview Operations]
C --> C1[list_candidates]
C --> C2[get_candidate]
C --> C3[create_candidate\nflat email/phone fields]
C --> C4[update_candidate\nflat email/phone fields]
C --> C5[search_candidates]
C --> C6[add_candidate_tag\nNEW]
C --> C7[remove_candidate_tag\nNEW]
D --> D1[list_applications\ncreatedAfter → epoch ms]
D --> D2[get_application]
D --> D3[create_application\n⚠ applicationId=r.applicationId always null]
D --> D4[change_application_stage\nNEW]
E --> E1[list_jobs]
E --> E2[get_job]
E --> E3[list_job_postings\nNEW]
E --> E4[get_job_posting\nNEW]
F --> F1[list_offers\nupdated shape from latestVersion]
F --> F2[get_offer\nNEW]
G --> G1[list_sources\nNEW]
G --> G2[list_candidate_tags\nNEW]
G --> G3[list_archive_reasons\nNEW]
G --> G4[list_custom_fields\nNEW]
G --> G5[list_departments\nNEW]
G --> G6[list_locations\nNEW fixed postalAddress]
G --> G7[list_openings\nNEW]
G --> G8[list_users\nNEW]
H --> H1[list_interviews\nNEW]
H --> H2[list_notes]
H --> H3[create_note\nnow returns noteId only]

Loading

_{Last reviewed commit: "fix(ashby): map remo..."}

[waleedlatif1]

Re: the summary review —

change_application_stage.ts — Fixed. application.changeStage returns a full application object, so updated to r.id and r.currentInterviewStage?.id.

create_note.ts — Fixed. The Note Object Schema shows notes use id, not noteId. Updated to r.id.

list_interviews.ts — Fixed. Added interviewStageId to the block UI condition so users can filter by interview stage.

create_application.ts — No change needed. The Ashby API docs for application.create explicitly show the response is { "applicationId": "...", "candidateId": "...", "jobId": "..." } — applicationId is correct, not id. This is a special create endpoint that returns IDs, not a full application object.

@greptile

[waleedlatif1]

Addressing the second round of review comments:

create_application.ts (P0) — Not fixing. The Ashby application.create endpoint explicitly returns { applicationId, candidateId, jobId } per the API docs. This is a create endpoint that returns IDs, not a full application object. r.applicationId is correct.

update_candidate.ts (P1) — Fixed. The API docs confirm the field is websiteUrl, not website. Updated body.website → body.websiteUrl.

Also rebased on origin/staging so our changes are the only commits on this branch.

@greptile

[waleedlatif1]

Addressing round 3 review comments:

get_candidate.ts (P1) — Fixed. Reverted body field from id back to candidateId. The candidate.info endpoint expects candidateId per the API docs.

get_job.ts (P1) — Fixed. Reverted body field from id back to jobId. The job.info endpoint expects jobId per the API docs.

create_application.ts (P0) — Not fixing. The API docs for application.createexplicitly show the response is { "applicationId": "e9ed20fd-..." }. This is NOT a full application object — it's a create endpoint that returns the ID in a field called applicationId. r.applicationId is correct.

@greptile

[waleedlatif1]

@greptile

[waleedlatif1]

Added subblock ID migrations for removed emailType → email and phoneType → phoneNumber to prevent breaking deployed workflows.

@greptile

[waleedlatif1]

Addressing round 4 review comments (all P2):

list_applications.ts — NaN on invalid date — Not fixing. The createdAfter input has a wand config that generates valid ISO 8601 timestamps. Passing null to the API is harmless (the filter is simply ignored). Adding validation for this edge case would be over-engineering.

create_application.ts — r.applicationId vs r.id — Not fixing (4th time). The API docs explicitly show the response as { "applicationId": "e9ed20fd-..." }. This is a create endpoint returning IDs, not a full application object.

ashby.ts — interviewStageId mode — Not fixing. The field is required for change_application_stage and must be visible. Adding mode: 'advanced' back risks hiding a required field. Showing it for create_application and list_interviews (where it's optional) is acceptable — it's a useful filter, not a rarely-used setting.

@greptile

[waleedlatif1]

Ran full integration validation (tools, block, registry, types, index). No critical or warning issues found:

• All 28 tools follow conventions (IDs, params, visibility, request patterns, error handling)
• Block ↔ tool alignment is correct (all operations in dropdown, conditions complete, required fields properly set)
• tools.config handles all param remapping correctly with type coercions in params (not tool)
• Advanced mode applied to optional fields, required fields in basic mode
• WandConfig on timestamp fields
• Subblock ID migrations in place for removed emailType/phoneType

@greptile

[waleedlatif1]

Good catch on the migration — emailType stored values like 'Work'/'Personal', not email addresses. Mapping those into email would corrupt the field. Fixed by mapping to dummy keys (_removed_emailType, _removed_phoneType) so the old values are carried harmlessly without overwriting real data.

@greptile