Candidate submission portal for your Bullhorn job orders

Build me an app my recruiters open whenever they are ready to put candidates in front of a client. Today that means exporting CVs and emailing PDFs around, and I want the whole ritual to happen on one screen: pick the job, tick the candidates, edit the blurb, send. Sending must both create the submission records in Bullhorn and email a clean shortlist to the client.

The first screen is a list of my open Bullhorn job orders. For each job show the job title, the client company, the job owner, how many days it has been open, and how many candidates are already submitted. Default the list to only the job orders owned by the recruiter using the app, and give them a toggle to switch to the whole desk. Resolve the current recruiter from the Bullhorn user behind the connected account; if that cannot be matched confidently, let them choose their name from a list of owners and remember the choice. Sort by days open descending so stale jobs surface, and let them search by job title or client name.

Opening a job goes to a job detail screen showing every candidate available to put forward. That is two groups merged into one list: candidates currently in that job's pipeline (the existing submissions on the job order) and the candidates sitting on the tearsheet linked to that job. Label which group each candidate came from, and mark anyone already submitted so nobody gets sent twice. For each candidate show name, headline, availability, rate, and the internal details the recruiter needs to make the call. Internal detail is fine to display inside the app; it just must never reach the email.

The recruiter ticks the two or three candidates they want to put forward. For each ticked candidate, auto-draft a one paragraph summary written for the client, pitching why this person fits this specific job, using the candidate's own record and the job order's requirements. Show each draft in an editable text box next to the candidate so the recruiter can rewrite it in their own voice. Keep the drafts to a single tight paragraph. Give them a preview of the outgoing email rendered exactly as the client will see it before they commit.

Send does two things. First, create a submission in Bullhorn for each ticked candidate against that job order using the Create Job Submission operation. Second, send the formatted shortlist to the job's client contact using the Gmail Send a Message operation, from the recruiter's own mailbox, with a subject naming the role and the client. If a candidate's submission fails to create, tell the recruiter which one and do not silently drop it from the email. If the job order has no client contact, ask the recruiter to pick a recipient rather than guessing.

The outgoing email must be client safe. Include only the candidate name, headline, availability, rate and the recruiter's paragraph, for each candidate, plus a short intro naming the role. Never include internal notes, margin, pay rate, candidate ID, or any other internal field. Build the email body from an explicit allowlist of those fields rather than dumping the candidate record, so a new field appearing in Bullhorn can never leak into a client's inbox.

Bullhorn specifics the handlers need to respect. Log in exactly once per run with the Authenticate and Get Session operation, then reuse the returned BhRestToken and restUrl for every following call; the access token backs a single login, so a second login attempt in the same run will fail. Read job orders, submissions and candidates through the entity search endpoints with Lucene syntax, and use the query endpoints for entities that do not support search, such as Tearsheet. Every read needs an explicit fields parameter, so name the fields you want including nested ones like the client corporation name and the owner name. Remember that PUT creates records and POST updates them, which is backwards from most APIs. All timestamps are epoch milliseconds, so convert before working out days open.

Persist enough to make the app feel like it remembers: each recruiter's desk toggle, and a local record of what was sent for each job (which candidates, to which contact, when, and the blurb that went out). Show that send history on the job detail screen so a recruiter picking the job back up can see what the client has already been shown. Handle the empty and slow states properly: a job with nobody in the pipeline and nothing on the tearsheet should say so, and the list should stay usable while Bullhorn is paginating.