Ellipse Gradient for Header

Bullhorn Integration Guide

Connect Bullhorn recruiting and staffing data with enterprise applications through its REST API, selected webhook notifications, batch operations, and file APIs.

Bullhorn integration options at a glance

Bullhorn’s primary integration surface is its REST API, which supports entity retrieval and updates, searches, associations, metadata, field selection, and related operations for Candidates, JobOrders, ClientContacts, Corporations, Placements, and JobSubmissions. Bullhorn also provides webhook-style notifications for selected events, batch-oriented operations for supported entities, and file and note APIs for supported records. OAuth 2.0 secures API access using access and refresh tokens together with corporation-specific context. Martini can consume these APIs, receive selected webhook notifications, schedule incremental synchronization workflows, map and transform data, route files, and expose normalized APIs for downstream applications.

Integration pointSupported by Bullhorn?Common use casesHow Martini supports it
REST APIsYesRetrieve, search, update, and associate Candidates, JobOrders, ClientContacts, Corporations, Placements, and JobSubmissions. Field selection, expansion, metadata, notes, and related operations are also available.Martini can consume Bullhorn REST endpoints from workflows, manage request configuration, transform responses, apply business rules, and expose normalized APIs.
Webhooks / outbound callbacksLimitedReceive notifications for selected Bullhorn entity events and changes. Coverage, subscription behavior, payload completeness, and tenant availability must be verified.Martini can expose an API endpoint or workflow trigger, validate incoming requests, acknowledge promptly, and process events asynchronously with reconciliation logic.
Bulk / batch / asynchronous operationsLimitedReduce request volume for supported entities and operations through documented batch-oriented API capabilities. Coverage is not universal across all operations.Martini can orchestrate batch requests, inspect partial results, retry failed items, and fall back to paginated incremental workflows where batch support is unavailable.
File / attachment APIsYesRetrieve or upload supported files and notes associated with Candidates, JobOrders, and other supported entities, including resumes and staffing documents.Martini can retrieve content, preserve metadata and source identifiers, transform payloads, route files to target applications, and prevent duplicate transfers.
AuthenticationYesOAuth 2.0 authorizes REST API access using client credentials, authorization code exchange, access and refresh tokens, user permissions, and corporation-specific REST context.Martini can store secrets securely, call authenticated endpoints, refresh tokens, and separate environment-specific corporation configuration from workflow logic.
Scheduled synchronizationYesPaginated searches and incremental queries can synchronize objects when a required event is unavailable or when reconciliation is needed.Martini can schedule workflows, persist checkpoints, use overlapping windows, apply idempotent writes, and record synchronization outcomes.
Database accessNoDirect SQL access to the underlying Bullhorn application database is not confirmed and should not be used as an integration surface.Martini should use Bullhorn APIs, webhooks, or supported exports rather than attempting a direct database connection.
GraphQL APIsNot confirmedNo official Bullhorn GraphQL API was confirmed in the supplied research.Martini can consume GraphQL APIs generally, but Bullhorn integrations should use the documented REST API unless GraphQL access is separately confirmed.

How Bullhorn exposes data and business events

Bullhorn REST APIs

Bullhorn’s REST API is the primary documented integration surface. It supports retrieval, search, updates, associations, field selection, expansion, metadata inspection, notes, files, and selected batch-oriented operations for business objects such as Candidates, JobOrders, Corporations, Placements, and JobSubmissions.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with OAuth 2.0, calls the corporation-specific Bullhorn REST URL, retrieves paginated or incrementally changed data, follows required associations, maps the response to a canonical model, and writes to one or more target systems. The workflow records checkpoints, correlation identifiers, and failures for replay.

Implementation sequence

Obtain or refresh the Bullhorn OAuth access token
Call the corporation-specific Bullhorn REST endpoint
Retrieve the selected objects and required associations
Map Bullhorn fields to the canonical integration model
Apply validation, routing, and idempotency rules
Write the transformed data to the target system and store synchronization state

Bullhorn Webhook Notifications

Bullhorn supports webhook-style notifications for selected entities and events. Notifications are not a universal event stream, and event coverage, payload detail, subscriptions, delivery behavior, and tenant availability must be confirmed for each integration.

Martini implementation pattern

Martini implementation pattern: expose a controlled Martini API endpoint or workflow trigger, validate the inbound request, acknowledge quickly, and hand off longer processing asynchronously. When the notification contains only an identifier or incomplete data, Martini retrieves the current Bullhorn object through the REST API before applying downstream business rules.

Implementation sequence

Receive the Bullhorn webhook notification
Validate the request and identify the event and source object
Record an idempotency key and acknowledge promptly
Retrieve the current Bullhorn object when the payload is incomplete
Map and route the event through the Martini workflow
Write downstream changes and retain the event outcome for replay or reconciliation

Bullhorn Batch Operations

Bullhorn documents batch-oriented API capabilities for supported entities and operations. Batch processing can reduce HTTP request volume, but it does not imply that every object supports arbitrary bulk create, update, or delete operations.

Martini implementation pattern

Martini implementation pattern: partition work into provider-supported batches, submit requests through the REST API, inspect item-level results, and separate successful, validation, permission, and transient failures. For large or unsupported operations, Martini uses paginated searches and incremental checkpoints instead of an unrestricted export.

Implementation sequence

Identify whether the required entity and operation support batching
Partition the source work into bounded requests
Submit the batch through the Bullhorn REST API
Inspect item-level responses and classify failures
Retry transient failures without repeating successful items
Persist completion state and route permanent failures for review

Bullhorn File and Note APIs

Bullhorn provides file and note-related operations for supported entities. These capabilities can support resumes, candidate documents, job-order documents, and other staffing attachments, subject to the behavior of the relevant endpoint and entity.

Martini implementation pattern

Martini implementation pattern: retrieve supported content and metadata, validate access and content type, transform or encode the payload when required, and deliver it to a repository or downstream application. Source entity IDs, file names, timestamps, categories, and duplicate-detection values remain part of the processing context.

Implementation sequence

Identify the supported Bullhorn entity and file operation
Retrieve file content and metadata through the REST API
Validate permissions, content type, and retention requirements
Map metadata and transform the file payload if required
Upload the file to the target repository or application
Store the source identifier and transfer result for reconciliation

Common Bullhorn integration patterns

Pattern 1: Synchronize candidates and placements to workforce systems

When to use this pattern

Use this pattern when Workday, payroll, HR, or workforce-management processes require current Candidate and Placement data. A scheduled or incremental workflow is appropriate when webhook coverage does not include every required change.

Integration direction
Bullhorn
Martini
Workday
Example Mapping
Bullhorn FieldCanonical FieldTarget Field
Candidate.idsourceCandidateIdWorker.externalCandidateId
Candidate.firstNameperson.firstNameWorker.firstName
Placement.statusplacement.statusAssignment.status
Placement.dateBeginplacement.startDateAssignment.startDate
Martini implementation pattern

A scheduler starts the workflow, which queries changed Candidates, JobSubmissions, and Placements using bounded windows and pagination. Martini follows Candidate and JobOrder associations, maps data into a canonical workforce model, applies eligibility and status rules, and performs idempotent create-or-update operations. Transient failures are retried, while validation and permission errors are logged with the source identifiers for review.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination and checkpointing
  • data mapping
  • business rules
  • idempotent writes
  • error handling

Pattern 2: Distribute approved job orders to external applications

When to use this pattern

Use this pattern when approved Bullhorn JobOrders must be distributed to a CRM, job-distribution process, portal, or external recruiting application while keeping internal and candidate-facing fields separate.

Integration direction
Bullhorn
Martini
Salesforce
Example Mapping
Bullhorn FieldCanonical FieldTarget Field
JobOrder.idsourceJobOrderIdOpportunity.externalBullhornId
JobOrder.titlejob.titleOpportunity.jobTitle
JobOrder.descriptionjob.publicDescriptionOpportunity.description
Corporation.nameclient.nameAccount.name
Martini implementation pattern

Martini retrieves approved JobOrders and related Corporations and ClientContacts, filters fields according to publication rules, and transforms the result for the target application. Business rules can suppress confidential fields, route by client or region, and prevent duplicate postings. The workflow records the Bullhorn source ID and target ID so retries update the existing result rather than creating another one.

Martini capabilities used
  • REST API consumption
  • association retrieval
  • data mapping
  • field filtering
  • conditional routing
  • idempotency
  • retry handling

Pattern 3: Process candidate events through onboarding workflows

When to use this pattern

Use this pattern when selected Bullhorn candidate or placement events should initiate downstream onboarding, compliance, notification, or service activity. The required event and entity coverage must be verified before relying on webhooks.

Integration direction
Bullhorn
Martini
ServiceNow
Example Mapping
Bullhorn FieldCanonical FieldTarget Field
Candidate.idcandidate.sourceIdTask.bullhornCandidateId
Candidate.statuscandidate.statusTask.triggerStatus
Placement.idplacement.sourceIdTask.placementId
ClientContact.emailclientContact.emailTask.requesterEmail
Martini implementation pattern

Bullhorn sends a supported notification to a Martini API endpoint. Martini validates and deduplicates the request, retrieves the current Candidate or Placement when necessary, applies status and routing rules, and creates or updates a ServiceNow task. The workflow acknowledges quickly, processes asynchronously where appropriate, and uses scheduled reconciliation for missed or unsupported events.

Martini capabilities used
  • API exposure
  • webhook consumption
  • asynchronous workflows
  • data enrichment
  • business rules
  • deduplication
  • reconciliation

Pattern 4: Synchronize recruiting documents to a repository

When to use this pattern

Use this pattern when resumes, placement documents, notes, or job-order attachments must be retained in an enterprise repository such as Microsoft SharePoint or sent to a downstream HR process.

Integration direction
Bullhorn
Martini
Microsoft SharePoint
Example Mapping
Bullhorn FieldCanonical FieldTarget Field
Candidate.idsourceEntityIdDocument.bullhornEntityId
file.namedocument.fileNameDocument.name
file.contentTypedocument.contentTypeDocument.mimeType
file.dateLastModifieddocument.modifiedAtDocument.modifiedAt
Martini implementation pattern

A Martini workflow retrieves supported Bullhorn files and notes, validates access and metadata, and uploads the content to the target repository. It preserves the source entity, category, timestamp, and a stable duplicate-detection key. Failed downloads, unsupported formats, permission issues, and downstream upload errors are classified separately so the workflow can retry safely.

Martini capabilities used
  • file API consumption
  • content transformation
  • metadata mapping
  • secure configuration
  • duplicate detection
  • error handling
  • workflow monitoring

Applications commonly integrated with Bullhorn

Bullhorn data can be coordinated with adjacent business applications when recruiting, staffing, document, onboarding, customer, or financial processes cross system boundaries. The exact objects, fields, and direction should be confirmed for the Bullhorn product configuration and each target application.

Application Scenario Direction Martini Pattern
Salesforce Synchronize staffing clients, contacts, opportunities, and recruiting activity with a CRM. Bullhorn → Martini → Salesforce Martini can retrieve Bullhorn Corporations, ClientContacts, JobOrders, and related activity, map them to Salesforce objects, apply ownership and deduplication rules, and send approved Salesforce changes back to Bullhorn where required.
NetSuite Transfer placement, client, billing, or payroll-related information into financial and operational processes. Bullhorn → Martini → NetSuite A scheduled Martini workflow can retrieve eligible Placements and related client data, normalize identifiers and amounts, apply approval rules, and submit the result to NetSuite while recording correlation and retry state.
Workday Send candidate, placement, and onboarding information to an HCM platform. Bullhorn → Martini → Workday Martini can query changed Candidates and Placements, follow relevant associations, transform staffing fields into the Workday contract, and isolate validation or permission failures for review.
ServiceNow Create onboarding, service, or operational tasks from candidate, placement, or client events. Bullhorn → Martini → ServiceNow Bullhorn webhook notifications or scheduled REST queries can start a Martini workflow that enriches the event, applies routing rules, and creates or updates ServiceNow tasks idempotently.
DocuSign Initiate and track signatures for staffing agreements, offer documents, or onboarding paperwork. Bullhorn → Martini → DocuSign Martini can retrieve eligible Bullhorn documents or business data, create a DocuSign envelope, and process returned status notifications before updating the relevant Bullhorn object or workflow state.
Microsoft SharePoint Store resumes, placement documents, and client files in an enterprise document repository. Bullhorn → Martini → Microsoft SharePoint A Martini workflow can retrieve supported Bullhorn files, preserve source identifiers and metadata, apply access and retention rules, and upload the content to SharePoint with duplicate detection.
Jira Create implementation, onboarding, or operational tasks from placement and customer-service events. Bullhorn → Martini → Jira Martini can route Bullhorn events or scheduled changes to Jira, map statuses and ownership, add source identifiers to issues, and retry transient downstream failures without duplicating tasks.
Indeed Support job distribution and recruiting workflows involving external job information. Bullhorn → Martini → Indeed Where the relevant Bullhorn and Indeed capabilities are configured, Martini can transform approved JobOrder data into the required downstream contract, enforce publication rules, and reconcile responses or status changes.

How to build a Bullhorn integration in Martini

Objective

Establish Bullhorn API access using the tenant’s OAuth 2.0 configuration and corporation-specific context without placing credentials in workflow definitions.

Instructions in Martini

  • Register or obtain the Bullhorn application credentials
  • Store the client secret, refresh token, access token, and corporation-specific values as protected Martini configuration
  • Configure token refresh and confirm the API user has required permissions
  • Test access to the required Bullhorn entities and operations

Objective

Select an event-driven, scheduled, or API-led entry point based on the required Bullhorn event coverage and synchronization latency.

Instructions in Martini

  • Use a Martini API endpoint or workflow trigger for supported Bullhorn webhook notifications
  • Use a scheduler for reconciliation and changes not covered by webhooks
  • Define the event, timestamp, identifier, or status checkpoint
  • Specify the expected response and asynchronous processing behavior

Objective

Retrieve current Bullhorn objects and associations with bounded, efficient API requests rather than assuming that event payloads contain complete data.

Instructions in Martini

  • Call the Bullhorn REST API with field selection and appropriate searches
  • Handle pagination for every collection response
  • Retrieve related Candidates, JobOrders, Corporations, ClientContacts, Placements, or JobSubmissions as required
  • Persist a cursor, timestamp, or last-processed identifier

Objective

Coordinate enrichment, routing, target writes, and state management in a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, transformation, business rules, and target delivery stages
  • Use correlation IDs based on Bullhorn object identifiers and event information
  • Route independent target operations explicitly
  • Process longer webhook work asynchronously where appropriate

Objective

Convert Bullhorn’s relational and tenant-specific model into a canonical contract and the target application’s required structure.

Instructions in Martini

  • Map actual Bullhorn objects and fields to canonical fields
  • Handle custom fields and optional associations conservatively
  • Transform dates, statuses, identifiers, files, and nested relationships
  • Validate required values before sending downstream

Objective

Control publication, eligibility, ownership, status, privacy, and duplicate behavior before changing downstream systems.

Instructions in Martini

  • Filter confidential or internal-only fields
  • Apply status and approval rules for Candidates, JobOrders, JobSubmissions, and Placements
  • Resolve duplicates using stable source identifiers
  • Enforce access, retention, and personal-information handling rules

Common Bullhorn data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
CandidateRepresent a person managed through recruiting and staffing processes, including candidate details and related submissions, placements, notes, or files.Workday, Salesforce, ServiceNow, SharePoint, DocuSignMartini retrieves Candidates through REST searches or supported events, follows required associations, maps tenant-specific fields, and uses the Bullhorn ID as a correlation key.
JobOrderRepresent a client job or staffing requirement, including approved job-posting and recruiting information.Salesforce, Indeed, Jira, customer portals, SharePointMartini separates internal and public fields, enriches the JobOrder with Corporation and ClientContact data, applies publication rules, and routes the transformed result.
ClientContactRepresent an individual contact associated with a client organization.Salesforce, NetSuite, customer portalsMartini maps contact identity and relationship data, applies consent and ownership rules, and performs create-or-update processing in downstream systems.
CorporationRepresent a client or company organization associated with staffing activity.Salesforce, NetSuite, WorkdayMartini synchronizes organization identifiers and approved attributes, resolves duplicates, and links Corporation data to JobOrders, ClientContacts, and Placements.
PlacementRepresent the placement of a Candidate into a JobOrder and support downstream onboarding, workforce, or financial processes.Workday, NetSuite, ServiceNow, SalesforceMartini retrieves related Candidate and JobOrder information, applies status and eligibility rules, maps the placement to the target contract, and records processing state.
JobSubmissionRepresent a Candidate submission associated with a JobOrder during the recruiting process.Salesforce, Workday, ServiceNow, analytics platformsMartini synchronizes status changes and relationships, applies business rules for approved stages, and handles missing or deleted related objects explicitly.

Authentication and security considerations

OAuth 2.0 and corporation context

Bullhorn REST API access generally uses OAuth 2.0 with a client ID, client secret, authorization code exchange, access token, refresh token, and corporation-specific REST context. The permissions of the Bullhorn user or API account govern the available entities and operations.

Protect credentials and personal information

  • Store client secrets, access tokens, refresh tokens, and corporation-specific values in protected Martini environment configuration.
  • Use least-privilege Bullhorn users or API accounts and confirm permissions for every required object and operation.
  • Protect candidate information, resumes, placement documents, and other personal data in transit, at rest, and in workflow logs.
  • Apply retention, access-control, audit, redaction, and regional data-processing requirements appropriate to the integration.

Operational considerations for Bullhorn integrations

Request volume and pagination

Use field selection, server-side searches, pagination, bounded windows, and incremental checkpoints. Confirm Bullhorn rate limits and add backoff for throttling and transient HTTP failures.

Consistency and idempotency

Use stable Bullhorn object IDs and event identifiers where available. Overlap synchronization windows to capture updates during a run, and make downstream create-or-update behavior explicit so retries do not create duplicates.

Webhooks and reconciliation

Treat webhook notifications as selected-event coverage rather than a complete event stream. Acknowledge promptly, process longer work asynchronously, and retain scheduled reconciliation for missed, delayed, or unsupported events.

Schema, associations, and testing

Bullhorn tenants can differ in custom fields, statuses, required values, and associations. Version mappings, inspect metadata where appropriate, test representative objects and files, and monitor changes that affect contracts.

Files and failures

Handle attachment permissions, content types, duplicate detection, and retention separately from ordinary object synchronization. Classify authentication, permission, validation, missing-object, rate-limit, network, partial-batch, and expired-webhook failures for targeted retry or review.

Why use Martini instead of scripts or point-to-point integrations?

Coordinate more than API calls

Scripts can call Bullhorn, but enterprise integrations also require authentication lifecycle management, pagination, association retrieval, mapping, business rules, idempotency, retries, file handling, and operational visibility. Martini provides a workflow-oriented place to coordinate these concerns.

Keep contracts maintainable

Martini can map Bullhorn’s tenant-specific model into canonical and target contracts, expose normalized APIs, and reuse authentication, transformation, validation, and error-handling assets across workflows.

Support multiple execution models

The same integration design can combine Bullhorn webhook notifications for selected events with scheduled incremental synchronization for reconciliation and unsupported changes. This reduces dependence on either a single event mechanism or a collection of isolated scripts.

Improve operational control

Centralized workflows provide explicit checkpoints, correlation identifiers, retry behavior, monitoring, and deployment configuration. Teams can evolve mappings and target integrations without embedding all logic in point-to-point code.

Frequently asked questions

How can Bullhorn be integrated with enterprise systems?

Bullhorn can be integrated primarily through its REST API, which supports searches, retrieval, updates, associations, metadata, and related operations for recruiting and staffing objects. Selected Bullhorn events can also generate webhook-style notifications, while batch operations and file or note APIs support particular use cases. OAuth 2.0 is used for API authorization, and scheduled incremental synchronization can cover changes that are not available through webhooks.

Can Martini integrate with Bullhorn?

Yes. Martini can integrate with Bullhorn by consuming the Bullhorn REST API, receiving supported webhook notifications through a Martini API or workflow trigger, processing supported files, and orchestrating scheduled or batch-oriented synchronization. No dedicated Martini Bullhorn connector is confirmed in the supplied information.

Do I need a connector to integrate Bullhorn with Martini?

No. A dedicated Bullhorn connector is not required. Martini can use Bullhorn’s confirmed native integration mechanisms, including its REST API, OAuth 2.0 authentication, selected webhook notifications, batch operations, and supported file or note APIs.

Is there any extra Lonti cost to integrate Bullhorn with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Bullhorn. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Bullhorn, infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.

Which Bullhorn integration methods should be used for a new integration?

Bullhorn’s REST API is the primary documented integration surface and should generally be the starting point. Selected webhook notifications can reduce latency for supported events, while scheduled incremental REST workflows provide reconciliation and coverage for changes without notifications. Bullhorn GraphQL and a current recommended SOAP API were not confirmed.

Can Martini receive Bullhorn webhook events?

Yes, where the required Bullhorn webhook event is supported and configured. Coverage is entity- and event-specific, so the required create, update, delete, status, custom-field, subscription, and delivery behavior should be confirmed for the customer’s edition and tenant. Martini can validate the request, acknowledge promptly, retrieve the current object, and process the event asynchronously.

How does Martini synchronize Bullhorn data and handle mapping?

Martini can use paginated searches, field selection, associations, timestamps, identifiers, or status criteria to implement incremental synchronization. It maps Candidates, JobOrders, ClientContacts, Corporations, Placements, and JobSubmissions into canonical and target models, applies tenant-specific field rules, follows relationships, and stores checkpoints and source identifiers for reconciliation.

How are Bullhorn errors, retries, and duplicate events handled, and can Martini expose an API façade?

Martini can classify authentication, permission, validation, missing-object, throttling, network, batch-item, and webhook failures separately, retry transient failures, and use Bullhorn object IDs and event information for idempotency. Martini can also expose a normalized REST API over Bullhorn data, applying authorization, business rules, transformations, and a stable organization-specific contract.

Related Martini documentation

API Integration

Workflows

Data Processing

Security

Operations

Connect Bullhorn with your enterprise systems

Use Martini to build secure, maintainable Bullhorn integrations across APIs, webhook notifications, files, workflows, and downstream applications.

EXPLORE MARTINI
BOOK A DEMO