Applications

Candidates apply on a job’s Apply tab on hotfix.jobs. The application lands on the job in Hotfix. Most hiring calls take one application_id. Start with list_applications or get_application. On MCP, agents use their own tools instead. On HTTP, list_applications defaults to status=new.

Change status

Statuses are new, considering (Reviewed in the apps), interviewing, hired, or rejected. Saving a review moves a new application to considering. set_status moves one row. It does not send email. A signed-in applicant sees fewer stages in their Watchlist: Under review (new and considering), Interviewing, Offer, Hired, Not moving forward, or Withdrawn. A rejection shows once its letter sends or, with no letter scheduled, three business days after the move. The application record’s candidate_sees returns what they see now, and rejection_shows_at says when a rejection will show. To change many rows at once, send their ids to bulk_update_applications with the same fields. It changes each row as set_status would, up to 100 per request, and lists any it could not change under failed while the rest still apply. Useful filters on list:

• status=all for every status
• status=rejected for rejected rows, including knockout failures
• visibility=archived or visibility=all to see archived rows (default active)
• view=interviews for booked and not started
• view=offers for an offer waiting on the candidate
• since as an ISO-8601 datetime on applied_at

Search notes, email, and resumes

q on list_applications matches name or email only. To find someone by what was written about them or to them, call search_applications with q. It looks in:

• name and email
• notes
• email: the subject and a preview, not whole message bodies. With an API key, it matches only what Hotfix sent, never reply text. Only the dashboard’s search, signed in, also reads the preview of a thread’s latest message, which can be the candidate’s reply.
• resumes, once Hotfix has made its text copy, usually within a minute of the application arriving

Archived and rejected rows are included. Each result is one application with up to three matches, each with its source (name, email, note, mail, or resume) and a snippet. A term matches whole words and their forms, so interview finds “interviewed”, and also text inside words. Results are matches, not a ranking.

Archive a row

Archive hides a row from the default list without changing its status. On HTTP, PATCH the row with archived: true (set_status route); archived: false restores it. Archived rows show under visibility=archived or visibility=all. Rejecting a row also archives it, and moving it out of rejected restores it. status=rejected with no visibility includes archived rows.

Knockouts

An applicant who fails a knockout lands in rejected, so archived. The applicant is not told. get_application returns knockout: true and knockout_reasons, the knockouts they failed on the job’s current form.

Read answers, markdown, and the resume

get_application includes answers. Hotfix keeps the resume and a text copy for you, and doesn’t check it against the job.

• Send Accept: text/markdown for the markdown form.
• GET resume_text to read the resume word for word, as markdown or as extracted text.
• GET the resume path for the PDF. That path accepts a session, a company API key, or the MCP access token.

Custom fields

Your company has a set of custom fields, such as a salary expectation or who referred someone. Each application carries a value for each field.

• list_fields returns the library. Use each field’s key everywhere else.
• Applications return custom_fields, the current values by field id, and submitted_fields, what the candidate answered on the form. Your team never edits submitted_fields, so a value that still matches it is the candidate’s own answer.
• set_custom_field sets or clears one value. The change is logged in the application’s activity.
• Filter list_applications with field, for example field=salary_expectation>=150000. Repeat it to combine filters.

Where they came from

Each application has source, where they applied: search for anywhere on hotfix.jobs, like your company page, the job’s page, or Hotfix search, and site for the embed on your own site. It also has channel, the tag on the link they followed, such as linkedin or indeed. channel is null when they came direct. To tag a link, add ?source= to your company page or job URL, like https://hotfix.jobs/jobs/{job_id}?source=linkedin. The link parameter fills channel; the source field is always search or site. In the app, Copy tracking link on a job does this for you. On your own site, the embed passes your page’s ?source= along as the channel.

Add a note

add_note stores markdown on the row, attributed to the caller. It does not send email. list_notes returns every note on the row, oldest first.

Data retention

A company can have applicant data deleted 6, 12, or 24 months after an application closes (rejected, withdrawn, or its job closed), under Settings > Hiring. Hired applications are never deleted. See Privacy. A deleted application is gone from the API: it is not in list_applications or search, and get_application returns 404. Nothing is sent to your webhooks when it happens.

What this does not do

There is no send tool. A status change or archive does not write mail. Archived rows, including rejected rows and knockout failures, stay off the default list.