Breezy HR

Breezy HR

Breezy HR is an applicant tracking system for company hiring workflows, job positions, candidates, and pipeline stages.

Data Model

• Companies — top-level workspaces returned by the account. Some accounts can see more than one company; pass company_id explicitly after discovery in that case.
• Pipelines — ordered hiring stages for positions and talent pools. Stage ids such as applied, interviewing, offer, disqualified, and hired are the values used when moving candidates.
• Positions — job requisitions with a state such as draft, published, closed, or archived. Positions own candidates and hiring-team context.
• Candidates — applicant or sourced-candidate records nested under a position. Candidate list results are abbreviated; use candidate detail plus metadata when you need notes, documents, conversations, questionnaires, references, or scorecards.

Working Order

• Start with companies when the account can access more than one company; pass company_id explicitly after discovery.
• Read pipelines before moving candidates. Stage ids are pipeline-specific strings such as applied, interviewing, offer, disqualified, and hired.
• Read positions before working with candidates. Candidates are nested under a position, so candidate reads and writes require position_id.
• Use get tools with ids for detail lookups and without ids for lists. Use upsert tools for create/update.

Common Workflows

• Review the hiring pipeline by listing companies, reading the default pipeline stages, then listing published or draft positions.
• Triage a role by reading the position, listing candidates with page_size, and requesting candidate metadata for notes, documents, and conversation context only when needed.
• Create a sourced candidate by choosing the position, setting origin to sourced, and adding tags or source attribution so the hiring team can audit where the candidate came from.
• Move a candidate after checking pipeline stages. Use stable stage ids, not display names, when calling the stage-move tool.
• Clean up test or obsolete positions by setting position state to archived; do not look for candidate deletion because the public API does not document it.

Write Safety

• Position creation requires name, description, type, and location; archive smoke-created positions with state archived.
• Candidate creation requires name; email_address is required when the candidate origin is applied.
• There is no documented candidate delete endpoint in the public API. Use stage moves such as disqualified for workflow state changes.
• Updates are scoped to the company and position ids supplied. If a credential has multiple companies, ask for or use company_id rather than silently selecting one.