How to Send Email from Bullhorn with Volanea Using Zapier

Sending email from Bullhorn does not have to mean manually copying a candidate or contact record into a separate messaging tool. This guide shows how to send email from Bullhorn through Volanea by using Zapier as the secure workflow layer between Bullhorn CRM and Volanea’s REST email API.

Bullhorn does not provide a native Volanea app, marketplace listing, or direct Volanea plugin. Rather than pretending there is a one-click integration, this setup uses the Bullhorn CRM app in Zapier to detect a real Bullhorn event, then uses Zapier’s webhook capability to make the authenticated API request to Volanea.

What this integration does

The workflow in this guide sends a transactional email after Bullhorn CRM creates a new Candidate record. That is the concrete event: New Candidate in the Bullhorn CRM Zapier integration.

A recruiting team can use that event for a candidate acknowledgement, next-steps message, document checklist, consent notice, or recruiter-introduction email. The pattern also applies to other Bullhorn-supported Zap triggers, such as new client contacts, job orders, placements, notes, or tasks, but begin with one well-defined workflow before expanding it.

The path is:

1. A recruiter, import, form process, or integration creates a Candidate in Bullhorn.
2. Zapier’s Bullhorn CRM trigger detects the new Candidate.
3. Zapier maps selected Bullhorn fields into a JSON request body.
4. Zapier sends that JSON over HTTPS to Volanea’s email endpoint.
5. Volanea accepts the request, queues the message, and returns a response that Zapier can record or pass to later steps.

This is an automation, not a replacement for Bullhorn’s normal CRM communication history or recruiter workflow. Decide in advance whether these messages should also be represented in Bullhorn as notes, tasks, or email activity. A successful API send only establishes that Volanea accepted a message request; it does not automatically create a Bullhorn activity record unless you add a separate Zapier action to do that.

Why Zapier is the appropriate connection layer

Bullhorn’s publicly available integration options include API access and ecosystem integrations, but that does not mean every Bullhorn plan exposes a generic, customer-configurable outbound HTTP webhook that can directly call any email vendor. For this use case, the practical no-code route is the Bullhorn CRM integration in Zapier.

Zapier provides two important pieces that a direct browser-side implementation cannot safely provide:

• A managed trigger that can authenticate to Bullhorn and watch for a supported Bullhorn event.
• A server-side webhook action that can call Volanea with an HTTP authorization header without exposing the key to a recruiter, candidate, public form, or browser developer tools.

This distinction matters. Bullhorn is the source system and its New Candidate trigger starts the workflow, but Zapier constructs the outbound HTTP request. There is no single universal “Bullhorn webhook payload” for this setup because Zapier receives Bullhorn record fields and you explicitly define the request body sent to Volanea.

That explicit mapping is beneficial. It prevents accidental transmission of internal recruiter notes, compensation details, work authorization data, attachments, custom fields, or other data that a candidate should not receive. Send the minimum fields needed to deliver the message.

Before you build the Zap

Gather the accounts, permissions, and message decisions before opening the Zap editor. A clean design prevents the common outcome where an integration technically works but emails the wrong person, has an unmonitored reply address, or duplicates messages after a bulk import.

You will need:

• Access to the relevant Bullhorn CRM account and permission to connect it to Zapier.
• A Zapier plan with access to the Bullhorn CRM trigger and a webhook action where required by your Zapier plan.
• A Volanea API key with permission to send email.
• A verified sending domain and a From address configured for that domain in Volanea.
• A deliberate recipient policy: which Bullhorn email field is eligible for an automated email.
• An approved template and a monitored Reply-To mailbox.

For the Volanea-specific endpoint, authentication, sender-domain, and message-field requirements, keep the email API setup guides available while configuring the request. Do not infer a sender identity from a recruiter’s personal address merely because that address appears on a Bullhorn record.

Choose the correct Bullhorn email field

Candidate data can be incomplete, stale, imported from job boards, or intentionally withheld. In many Bullhorn configurations, a Candidate record has an email field, but not every record should receive a triggered message simply because the field is populated.

Create a filter rule in Zapier before the webhook action. At a minimum, continue only when the mapped candidate email exists. Depending on your process, add conditions such as a specific source, status, custom flag, consent field, or ownership rule. If a candidate must opt in before receiving non-essential mail, enforce that requirement in the Zap rather than relying on recruiter memory.

For a welcome or application-receipt email, the recipient should generally be the Candidate’s own email address. Do not map an owner, recruiter, client contact, or company email into to by mistake. Test with an internal address first.

Decide what “new” means operationally

The Zapier trigger is named New Candidate, but “new” has business consequences. A bulk data import, a restored integration, or a historical-record migration can create records that look new to the trigger. If an automated email would be inappropriate for imported records, include an explicit eligibility field or a source-based filter.

A robust approach is to add a custom Boolean-style field or workflow marker in Bullhorn such as “Send candidate acknowledgement.” The Zap checks that marker, sends once, then writes a completion marker back to Bullhorn in a later step. The exact custom-field availability and naming depend on your Bullhorn configuration, so use the fields your administrator has defined rather than assuming a standard field exists.

Build the Bullhorn trigger in Zapier

Create a new Zap and select Bullhorn CRM as the trigger application. Select the New Candidate trigger event. Connect the Bullhorn account requested by Zapier and choose the relevant settings exposed for your account.

After connecting, test the trigger with a non-production Candidate record that has a clearly recognizable name and a safe internal email address. The test data should include at least:

• Candidate ID
• First name
• Last name
• Email address
• Date or timestamp, if supplied by the trigger
• Any custom eligibility field you intend to filter on

Do not proceed until you inspect the returned test fields. Field labels can vary with connector version, Bullhorn configuration, and available record data. Zapier’s field picker is the source of truth for the values available in your specific Zap.

Add a filter before sending

Add a Zapier Filter step between New Candidate and the webhook request. A minimal filter is “Candidate email exists.” A safer production filter combines several conditions, for example:

1. Candidate email exists.
2. The address belongs to an allowed environment while testing, or the record has the required consent/status in production.
3. The record does not already carry a “welcome sent” or equivalent completion marker.
4. The candidate source is not a migration or bulk-import source.

A filter is not just a convenience. It is a data-control boundary. It ensures Volanea only receives the fields for records that are actually eligible for the communication.

Map the payload Zapier sends to Volanea

Add Webhooks by Zapier as the action and choose its custom request capability. Configure a POST request to Volanea’s email-send endpoint as documented in your Volanea account. Set the request format to JSON and add the appropriate API authorization and Content-Type headers.

The following example shows the request shape to build. Replace the illustrative endpoint and sender values with the exact values from your Volanea API documentation and account. In Zapier, each {{...}} placeholder is selected from the New Candidate trigger’s field picker; it is not literal text sent to Volanea.

{
  "from": "Talent Team <talent@example.com>",
  "to": [
    {
      "email": "{{Bullhorn New Candidate: Email}}",
      "name": "{{Bullhorn New Candidate: First Name}} {{Bullhorn New Candidate: Last Name}}"
    }
  ],
  "reply_to": "recruiting@example.com",
  "subject": "Thanks for connecting with Example Recruiting",
  "html": "<p>Hi {{Bullhorn New Candidate: First Name}},</p><p>Thanks for connecting with Example Recruiting. We received your details and a recruiter will review them shortly.</p><p>If you need to add information, reply to this email.</p>",
  "text": "Hi {{Bullhorn New Candidate: First Name}},\n\nThanks for connecting with Example Recruiting. We received your details and a recruiter will review them shortly.\n\nIf you need to add information, reply to this email.",
  "tags": [
    {
      "name": "source",
      "value": "bullhorn"
    },
    {
      "name": "event",
      "value": "new-candidate"
    },
    {
      "name": "candidate_id",
      "value": "{{Bullhorn New Candidate: ID}}"
    }
  ]
}

The important field mapping is straightforward:

Use a plain-text alternative as well as HTML. It improves readability in clients that do not render HTML and makes the content easier to inspect during testing. Keep the HTML simple: paragraphs, links, and clear text are safer than copied layouts with unsupported CSS or externally hosted scripts.

The equivalent REST call

The custom webhook action ultimately makes an HTTP request equivalent to the following. This is useful when your engineering team wants to reproduce the integration from a server-side service or compare Zapier’s request settings with the Volanea API reference.

curl --request POST "https://api.volanea.com/v1/emails" \
  --header "Authorization: Bearer $VOLANEA_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "from": "Talent Team <talent@example.com>",
    "to": [{
      "email": "candidate@example.net",
      "name": "Avery Jordan"
    }],
    "reply_to": "recruiting@example.com",
    "subject": "Thanks for connecting with Example Recruiting",
    "html": "<p>Hi Avery,</p><p>We received your details.</p>",
    "text": "Hi Avery,\n\nWe received your details.",
    "tags": [
      {"name": "source", "value": "bullhorn"},
      {"name": "event", "value": "new-candidate"},
      {"name": "candidate_id", "value": "12345"}
    ]
  }'

In Zapier, configure the headers as separate key/value entries:

Authorization: Bearer YOUR_VOLANEA_API_KEY
Content-Type: application/json

Use the exact endpoint and accepted JSON field names shown in the Volanea documentation for your account. If the API response includes a message ID, retain it in Zapier task history or write it to a controlled Bullhorn field or note where your operations team can reconcile a candidate inquiry with the sent message.

Keep the Volanea API key server-side

The Volanea API key belongs in the Webhooks by Zapier action’s authorization header, stored in Zapier’s authenticated configuration. It must not be placed in a Bullhorn candidate field, a public form, email HTML, a front-end JavaScript bundle, a browser-accessible configuration file, or a URL query string.

An email API key authorizes sending. If exposed, an attacker may send phishing, spam, or fraudulent messages from your verified domain, damage sender reputation, and consume sending capacity. Rotating a compromised key also breaks every integration that depends on it.

Use these operating rules:

• Create a dedicated Volanea key for this Bullhorn automation rather than sharing a broad personal key.
• Label the key by purpose, such as zapier-bullhorn-new-candidate-prod.
• Grant only the permissions the workflow needs where scoped keys are available.
• Limit Zap editing access to administrators who need it.
• Rotate the key on a schedule and immediately after a suspected exposure.
• Update the Zap’s protected header value during rotation, then retest with an internal address.

Do not paste the key into a code step’s output, an email body, a Slack notification, or a Bullhorn note. Those locations may be visible to far more people than the workflow’s administrators.

Design the email for recruiting operations

Recruiting messages are unusually sensitive because they can reveal a job search, application status, work history, or contact with an agency. The first message should be factual, expected, and easy to reply to.

A good acknowledgement includes the candidate’s first name, the organization or recruiting team name, a clear statement of what happened, realistic next steps, and a reply path. Avoid promising interviews, placements, timing, or job availability unless those claims are actually warranted.

Keep transactional and campaign use cases separate

A confirmation that Bullhorn received a candidate’s details is generally operational. A broad newsletter of open roles, recruiting tips, or marketing content is a campaign use case and needs a different consent, suppression, and segmentation approach.

Do not turn a New Candidate event into an automatic marketing subscription. The event may prove that a record was created, not that the person agreed to recurring promotional communication. Build a separate audience process and preserve consent evidence when campaign messages are appropriate.

Use tags for diagnosis, not sensitive data

Tags such as source=bullhorn, event=new-candidate, and an internal candidate identifier help analyze API activity. Do not put a candidate’s email address, résumé text, phone number, national ID, work authorization status, or other sensitive data in tags. Tags commonly appear in logs, exports, dashboards, and support investigations.

If an address has a history of bounces or is obviously malformed, correct it upstream before retrying. You can also check individual addresses with the email address verification tool before using them in a sensitive workflow.

Test the workflow safely

Begin in a test environment or with a test Candidate whose email you control. Do not use a real applicant’s address as your first test. Send the test, inspect the webhook action input and output, and confirm the received message in multiple mailbox providers if possible.

Verify all of the following before publishing:

• The recipient is the intended Candidate email, not a recruiter or client contact field.
• First and last names render correctly when one of them is blank.
• The From address uses your verified domain.
• Reply-To reaches a monitored inbox.
• The email contains no internal Bullhorn IDs, notes, private URLs, or recruiter-only fields.
• The plain-text part is readable.
• A second test does not create an unintended duplicate-send scenario.
• The Volanea response is successful and can be found in your sending records.

Then test edge cases deliberately: a Candidate with no last name, no email, a malformed email, a name containing apostrophes or accented characters, and a record created by an import. These cases expose mapping and filtering errors before they become production incidents.

When this breaks

Every integration has two boundaries: Bullhorn-to-Zapier and Zapier-to-Volanea. Troubleshooting gets much faster when you identify which boundary failed rather than treating “the email did not arrive” as one vague problem.

Retries can cause duplicate sends

Workflow platforms retry some failed or ambiguous actions. A timeout after the request reached Volanea is especially tricky: Zapier may not receive a response in time, while Volanea may still accept and queue the email. Retrying can therefore create two messages.

Reduce that risk with an idempotency design. The simplest no-code approach is a completion marker in Bullhorn: after a successful Volanea action, write a “sent” timestamp or status back to the Candidate and filter out records that already have it. This is not perfectly atomic—two concurrent runs can still race—but it is far safer than no state at all.

For high-volume or high-consequence workflows, use a small middleware service. It can store the Bullhorn candidate ID plus event type in a database with a unique constraint, send only once, and record Volanea’s message ID. That service can return a quick success response to the automation layer while it handles controlled retries.

Webhook timeouts and transient API errors

A webhook action can fail because of a network interruption, rate limit, an unavailable endpoint, a malformed request, or a server response that takes too long. Review Zapier task history first: it shows the action input, status, and response details available to the Zap.

A 401 or 403 typically points to an invalid, revoked, expired, or insufficiently scoped Volanea API key. A 400 or 422 usually means a payload issue, such as a missing sender, unverified From address, invalid recipient shape, or unsupported field. A 429 indicates throttling and should be handled through controlled retry rather than immediate repeated sends.

Do not respond to repeated failures by removing filters or disabling validation. Fix the exact request and resend a controlled test. If multiple tasks failed, assess whether replaying them would email people who have since been contacted through another channel.

Missing Bullhorn fields or plan-specific availability

Bullhorn configurations vary. Custom fields, API permissions, connector capabilities, and available data may differ across accounts and plans. A field visible to a recruiter in Bullhorn may not be exposed by the Zapier trigger, may be blank on records created by a certain source, or may require administrator configuration.

Inspect the trigger’s sample data and live task input instead of assuming every Candidate carries the same fields. If your consent marker or preferred email is unavailable, ask the Bullhorn administrator whether it is populated consistently and exposed to the integration. Do not substitute a loosely related field merely to make the Zap run.

The email is accepted but not in the inbox

A successful API response means the sending platform accepted the message. It is not a guarantee that the recipient saw it in the primary inbox. Check the recipient address, sending-domain authentication, suppression status, delivery events, mailbox spam folders, and the actual content.

Recruiting email can be filtered when it resembles bulk outreach, uses vague subjects, contains too many links, or comes from a domain without properly configured authentication. Keep initial transactional content concise and expected, and use a domain that recipients can identify as belonging to your organization.

Alternatives to a Zapier webhook action

Zapier is appropriate when the workflow is low to moderate volume, the mapping is simple, and operations staff need to maintain it without deploying code. It is not the only architecture.

A middleware service is a better fit when you need strict idempotency, detailed audit logs, advanced branching, enrichment, queueing, custom retries, encryption controls, or a high event volume. In that design, Bullhorn data still enters through an approved integration path, but your service owns transformation and the Volanea API request.

A custom Bullhorn API integration can also be appropriate for teams with engineering resources and the necessary Bullhorn API access. It should run on a server, protect both Bullhorn and Volanea credentials, log only necessary personal data, and apply the same consent and duplicate-prevention policies described here.

Avoid browser-side calls to the Volanea API. Even if a front-end form can technically make an HTTP request, exposing a sending key and allowing uncontrolled client input creates a security and abuse risk.

Operational checklist and conclusion

To send email from Bullhorn reliably, treat the Zap as a production workflow rather than a one-off convenience. The trigger should be a deliberate Bullhorn record event, the recipient must be eligible, the API key must remain inside Zapier’s protected server-side configuration, and each successful send should be traceable.

Before enabling the workflow for real candidates, confirm this checklist:

• Bullhorn CRM New Candidate is the intended trigger.
• A Filter prevents sends for blank, ineligible, imported, or already-processed records.
• Only required Candidate fields are mapped into the Volanea JSON body.
• The From domain is verified and Reply-To is monitored.
• The Volanea key is dedicated to this automation and stored only in Zapier’s header configuration.
• Tags contain operational identifiers only, not sensitive candidate information.
• A duplicate-prevention marker or middleware idempotency strategy exists.
• Your team knows where to inspect Zapier task history and Volanea delivery records.

That combination gives recruiters timely automation without hiding the important controls. Bullhorn remains the authoritative recruiting system, Zapier performs the secure orchestration, and Volanea handles the email send.

FAQ

Does Volanea have a native Bullhorn integration?

No. Volanea does not provide a native Bullhorn marketplace app or plugin. Use Bullhorn CRM through Zapier and make a server-side webhook request to Volanea, or build a custom middleware integration.

What Bullhorn event starts this workflow?

This guide uses the Bullhorn CRM Zapier trigger named New Candidate. It starts when Zapier detects a newly created Candidate record available through the connected Bullhorn integration.

Where should the Volanea API key be stored?

Store it in the protected authorization-header configuration of the Zapier webhook action. Never put it in a Bullhorn field, public form, browser code, URL, email content, or shared document.

How can I prevent the same candidate from receiving two emails?

Filter out already-processed records using a Bullhorn completion marker written after a successful send. For stronger protection, use middleware with a database-backed idempotency key based on the Candidate ID and event type.

Can I use this for marketing campaigns to candidates?

Use a separate, consent-based campaign workflow for marketing. A new Candidate record does not by itself establish permission for recurring promotional email; keep operational acknowledgements and campaign messaging distinct.