Ellipse Gradient for Header

Beamery Integration Guide

Connect Beamery talent and recruitment data with enterprise systems through REST APIs, scheduled workflows, and selected webhook-style event notifications.

Beamery integration options at a glance

Beamery’s primary enterprise integration mechanism is its REST API, which can be used to read and update Talent, Jobs, Pools, Tags, Notes, and other supported resources. Beamery may also provide webhook or event-notification capabilities for selected events, although coverage depends on the tenant and API version. Martini can authenticate with Beamery using provisioned OAuth 2.0-style credentials and bearer tokens, orchestrate paginated or incremental synchronization workflows, and transform Beamery payloads for downstream systems. General bulk APIs, public attachment APIs, GraphQL, SOAP, and direct database access were not confirmed, so large transfers and document synchronization should use only documented tenant capabilities.

Integration pointSupported by Beamery?Common use casesHow Martini supports it
REST APIsYesBeamery’s primary integration route for reading and updating Talent, Jobs, Pools, Tags, Notes, and other supported recruitment-related resources.Martini can consume Beamery REST endpoints, manage authenticated requests, paginate through responses, transform payloads, and call downstream APIs.
Webhooks / outbound callbacksLimitedBeamery may provide notifications for selected platform events, subject to tenant, edition, and API-version coverage.Martini can expose an API endpoint or workflow trigger, validate notifications, enforce idempotency, and retrieve the current object when needed.
AuthenticationYesBeamery API access uses provisioned OAuth 2.0-style credentials and bearer access tokens, with tenant-specific permissions and scopes to be confirmed.Martini can store credentials in protected secrets or environment configuration and include bearer tokens in API requests.
Bulk / asynchronous APIsNot confirmedNo general Beamery bulk or asynchronous API was confirmed; large transfers should use documented pagination, filtering, and incremental retrieval.Martini can schedule controlled batches, maintain checkpoints, limit concurrency, and reconcile partial runs.
File / attachment APIsNot confirmedBeamery may contain talent-related documents, but a general public attachment API was not confirmed.Martini can process files only when Beamery exposes documented document or attachment endpoints for the customer’s API version.
GraphQL APIsNot confirmedNo official Beamery GraphQL API was confirmed, so GraphQL should not be assumed as an integration method.Martini can consume GraphQL when a documented Beamery endpoint is provided, but REST should remain the default design.

How Beamery exposes data and business events

Beamery REST APIs

Beamery’s documented REST API is the primary integration method for talent and recruitment-related resources. Available endpoints, writable fields, relationships, pagination, and API versions should be confirmed for the customer tenant.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates to Beamery, retrieves or updates supported resources, follows pagination or incremental filters, maps the response to a canonical model, and calls target systems with controlled retries and reconciliation.

Implementation sequence

Authenticate with the Beamery-provisioned bearer-token flow
Retrieve the required Talent, Jobs, Pools, Tags, or Notes resources
Follow documented pagination and incremental filters
Map Beamery fields to the target data model
Apply validation, privacy, and business rules
Write approved data to the target system and store a checkpoint

Beamery webhook notifications

Beamery may support webhook or event notifications for selected platform events. Coverage is not assumed for every object or change and must be verified for the tenant and API version.

Martini implementation pattern

Martini implementation pattern: Martini exposes an authenticated API endpoint or workflow trigger, validates the incoming notification, checks event uniqueness, retrieves the current Beamery object when the payload is incomplete, and forwards a normalized event.

Implementation sequence

Receive the Beamery webhook notification
Authenticate and validate the request
Check the event identifier or deterministic deduplication key
Retrieve the current Beamery object when necessary
Map and route the normalized event
Acknowledge successful processing and retry transient failures

Scheduled Beamery synchronization

Where event coverage is incomplete or unavailable, scheduled synchronization can retrieve changed Beamery data through documented filters and pagination. Beamery bulk processing was not confirmed.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a controlled workflow, the workflow reads the last successful checkpoint, retrieves an overlap window of changes, processes pages with limited concurrency, and records results for reconciliation.

Implementation sequence

Start the scheduled Martini workflow
Load the last successful synchronization checkpoint
Retrieve changed resources using documented filters and pagination
Apply overlap-window and duplicate controls
Write valid changes to downstream systems
Persist the new checkpoint and report exceptions

Common Beamery integration patterns

Pattern 1: Synchronize Beamery Talent with an HR platform

When to use this pattern

Use this pattern when Beamery Talent profiles must be aligned with foundational HR or workforce data in Workday or SAP SuccessFactors. The design should define which system owns identity, employment, organizational, and recruiting fields.

Integration direction
Beamery
Martini
Workday
Example Mapping
Beamery FieldCanonical FieldTarget Field
Talent.idperson.externalIdWorkday worker reference
Talent.nameperson.displayNameWorkday worker name
Talent.emailperson.emailWorkday work email
Talent.tagsperson.classificationsWorkday configured classifications
Martini implementation pattern

Martini retrieves changed Talent objects through the Beamery REST API, filters sensitive or non-authoritative fields, normalizes identifiers and classifications, and calls the HR platform API. Idempotent writes, validation queues, rate-limit backoff, and reconciliation by identifier and update timestamp prevent duplicate or incomplete updates.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • secrets management
  • error handling

Pattern 2: Sync Jobs and candidates with an applicant-tracking system

When to use this pattern

Use this pattern when Beamery Jobs and Talent must exchange recruiting information with Greenhouse or Lever. The integration should separate requisition state from candidate state and establish ownership for status changes.

Integration direction
Greenhouse
Martini
Beamery
Example Mapping
Beamery FieldCanonical FieldTarget Field
Job.titlerequisition.titleBeamery Jobs.title
Job.statusrequisition.statusBeamery Jobs.status
Talent.idcandidate.externalIdATS candidate reference
Talent.tagscandidate.classificationsATS candidate tags
Martini implementation pattern

A Martini workflow retrieves incremental ATS data, maps requisitions and candidates to supported Beamery resources, validates required fields, and applies status and ownership rules. Failed records are isolated for review while transport failures use bounded retries and target writes use external identifiers for idempotency.

Martini capabilities used
  • workflow orchestration
  • API consumption
  • data transformation
  • validation
  • conditional routing
  • retry handling

Pattern 3: Process Beamery event notifications

When to use this pattern

Use this pattern when the Beamery tenant provides webhook-style notifications for the required events and downstream systems need near-real-time updates.

Integration direction
Beamery
Martini
Salesforce
Example Mapping
Beamery FieldCanonical FieldTarget Field
event.objectIdsourceObjectIdSalesforce external ID
event.typechangeTypeSalesforce event classification
Talent.emailcontact.emailSalesforce Email
Talent.tagscontact.classificationsSalesforce custom classification
Martini implementation pattern

Martini receives the notification through an API endpoint or workflow trigger, validates the request, checks an event ledger or deterministic key, retrieves the latest Talent object when needed, and sends only approved fields to Salesforce. Duplicate events are ignored safely and transient downstream failures are retried without reprocessing the source event.

Martini capabilities used
  • API exposure
  • workflow triggers
  • API consumption
  • idempotency rules
  • data mapping
  • error handling

Pattern 4: Export governed Beamery talent data

When to use this pattern

Use this pattern when selected Talent, Jobs, Pools, or Tags must be delivered to analytics, engagement, or workforce systems without copying the full Beamery profile.

Integration direction
Beamery
Martini
PostgreSQL
Example Mapping
Beamery FieldCanonical FieldTarget Field
Talent.idtalent.sourceIdtalent.source_id
Talent.updatedAttalent.lastChangedAttalent.updated_at
Talent.tagstalent.classificationstalent.tags_json
Job.idjob.sourceIdjob.source_id
Martini implementation pattern

A scheduled Martini workflow retrieves approved fields using pagination and incremental filters, removes or transforms sensitive attributes, writes normalized data to a persistence or analytics target, and records counts and checkpoints. Reconciliation compares identifiers and timestamps while invalid rows are diverted to an exception process.

Martini capabilities used
  • scheduled workflows
  • incremental synchronization
  • data minimization
  • JSON transformation
  • database integration
  • monitoring

Applications commonly integrated with Beamery

Beamery can be placed within a broader talent, recruiting, HR, CRM, and workforce-operations architecture. The exact objects, fields, permissions, and synchronization direction should be validated for each customer environment.

Application Scenario Direction Martini Pattern
Workday Synchronize worker, job, organization, and recruiting-related information with Beamery Talent and Jobs while preserving system-of-record boundaries. Workday → Martini → Beamery Martini schedules or receives approved changes, maps Workday identifiers and organizational data to Beamery fields, applies validation and privacy rules, and records reconciliation outcomes.
SAP SuccessFactors Align recruiting and employee information with Beamery talent pools and talent-management processes. SAP SuccessFactors → Martini → Beamery A Martini workflow retrieves changed SuccessFactors data, normalizes statuses and identifiers, updates supported Beamery resources, and routes validation failures for review.
Greenhouse Connect candidate and requisition information with Beamery Talent and Jobs to support sourcing and recruiting workflows. Greenhouse → Martini → Beamery Martini consumes the participating APIs, maps candidates and requisitions to Talent and Jobs, applies deduplication using external identifiers, and retries transient failures.
Lever Synchronize candidate and job information between the applicant-tracking environment and Beamery. Lever → Martini → Beamery A scheduled workflow retrieves incremental Lever changes, transforms candidate and job fields, applies configured ownership and status rules, and writes only supported Beamery fields.
Salesforce Share selected candidate, contact, account, or recruiting-related information with CRM processes. Beamery → Martini → Salesforce Martini retrieves approved Beamery Talent or related objects, minimizes sensitive fields, maps them to Salesforce structures, and handles duplicate and failed-write queues.
Slack Deliver selected recruiting or talent workflow notifications to internal teams. Beamery → Martini → Slack If suitable Beamery events are available, Martini receives or polls for changes, applies notification rules, and sends concise, privacy-aware messages to approved Slack destinations.

How to build a Beamery integration in Martini

Objective

Establish secure Beamery access using the tenant’s provisioned OAuth 2.0-style credentials, bearer tokens, scopes, and permissions.

Instructions in Martini

  • Confirm the Beamery tenant’s grant type, token endpoint, scopes, and API version.
  • Store client credentials and tokens in protected Martini secrets or environment configuration.
  • Use separate credentials and permissions for development, test, and production.

Objective

Select a scheduled workflow or verified Beamery webhook event based on the required freshness and event coverage.

Instructions in Martini

  • Use a scheduler when reliable event coverage is unavailable or incomplete.
  • Use a Martini API endpoint or workflow trigger only after the required Beamery events are confirmed.
  • Define the synchronization frequency, overlap window, and checkpoint strategy.

Objective

Read the required Beamery resources through documented REST endpoints while respecting pagination, filters, quotas, and concurrency limits.

Instructions in Martini

  • Retrieve only the Talent, Jobs, Pools, Tags, Notes, or Campaign fields required by the target.
  • Use documented incremental filters where available.
  • Handle pagination consistently and limit parallel requests.

Objective

Coordinate retrieval, enrichment, validation, routing, target writes, and checkpoint persistence in a maintainable Martini workflow.

Instructions in Martini

  • Separate authentication, retrieval, transformation, target delivery, and reconciliation stages.
  • Route validation failures separately from transport and server failures.
  • Persist progress so interrupted runs can resume safely.

Objective

Convert Beamery payloads into a canonical model and then into the target application’s structure.

Instructions in Martini

  • Map Beamery identifiers to stable external keys.
  • Normalize statuses, Tags, dates, relationships, and configurable fields.
  • Minimize sensitive Talent data and preserve only approved attributes.

Objective

Enforce business, privacy, ownership, and data-quality rules before writing to downstream systems.

Instructions in Martini

  • Validate required fields and configured enumerations.
  • Apply system-of-record rules for bidirectional updates.
  • Use idempotency keys to prevent duplicate downstream writes.

Common Beamery data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
TalentPeople or candidate profiles managed in Beamery and exchanged with recruiting, HR, or workforce systems.Workday, SAP SuccessFactors, Greenhouse, Lever, Salesforce, analytics platformsMartini retrieves or receives supported Talent data, minimizes sensitive fields, maps identifiers and statuses, and applies validation and deduplication rules.
JobsRoles or vacancies associated with hiring and talent activity.Workday, SAP SuccessFactors, Greenhouse, LeverMartini synchronizes supported job attributes, normalizes status and organizational references, and routes invalid values to exception handling.
PoolsGroups used to organize and manage talent.HR platforms, applicant-tracking systems, reporting storesMartini maps Pool identifiers and membership relationships where exposed, preserving source references for reconciliation.
CampaignsCoordinated talent engagement or recruitment activities.CRM platforms, engagement systems, reporting platformsMartini can retrieve or update supported Campaign fields, apply filtering rules, and forward approved data to downstream APIs.
TagsClassification labels applied to Talent and related Beamery objects.Workday, Salesforce, analytics platforms, data warehousesMartini uses explicit configuration mappings, validates permitted values, and handles newly introduced or retired Tags conservatively.
NotesRecruiter or user-entered information associated with Talent or related objects.Recruiting systems, CRM platforms, audit or reporting storesMartini transfers Notes only when permitted, applies data-minimization rules, and avoids exposing sensitive content in operational logs.

Authentication and security considerations

OAuth-style authentication and bearer tokens

Beamery API access is documented around provisioned OAuth 2.0-style authentication and bearer access tokens. The grant type, scopes, token endpoint, and tenant permissions should be confirmed during implementation.

Secrets and permissions

  • Store Beamery client credentials, access tokens, and refresh credentials in protected Martini secrets or environment configuration.
  • Use separate credentials and least-privilege permissions for development, test, and production.
  • Do not log complete Talent or candidate payloads because they may contain personal or sensitive information.

Operational considerations for Beamery integrations

Pagination and rate limits

Confirm Beamery pagination behavior, incremental filters, quotas, and burst limits. Use checkpoints, overlap windows, limited concurrency, and exponential backoff for retryable rate-limit responses.

Idempotency and reconciliation

Use Beamery object identifiers as external keys and event identifiers or deterministic keys for webhook notifications. Reconcile identifiers, counts, and update timestamps after synchronization runs.

Schema and data protection

Treat custom fields and Tags as configurable. Validate enumerated values, monitor API-version changes, minimize copied Talent data, and define retention, deletion, and correction behavior across systems.

Testing and monitoring

Test authentication, pagination, validation failures, duplicate delivery, rate limiting, and partial runs in a non-production tenant or environment. Monitor workflow logs and maintain an exception process for records that require review.

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

Orchestration instead of point-to-point code

Martini coordinates Beamery API calls, scheduled retrieval, optional event intake, transformations, business rules, target writes, and reconciliation in reusable workflows rather than scattering logic across scripts.

Maintainable data movement

Mappings, validation rules, checkpoints, retry behavior, and privacy filters can be managed as explicit integration assets. This makes changes to Beamery fields, Tags, target APIs, and synchronization policy easier to test and maintain.

Controlled enterprise delivery

Martini provides API consumption and exposure, secure configuration, workflow orchestration, error handling, and monitoring capabilities needed to operate Beamery integrations across environments and target systems.

Frequently asked questions

How can Beamery be integrated with enterprise systems?

Beamery can be integrated primarily through its REST APIs for Talent, Jobs, Pools, Tags, Notes, Campaigns, and other supported resources. Scheduled workflows can support paginated or incremental synchronization, while selected webhook-style notifications may support event-driven processing when enabled for the tenant and API version.

Can Martini integrate with Beamery?

Yes. Martini can consume Beamery’s documented REST APIs, authenticate using provisioned bearer-token credentials, orchestrate scheduled workflows, transform Beamery data, and receive webhook-style notifications when the required Beamery event coverage is available.

Do I need a connector to integrate Beamery with Martini?

No. A dedicated Beamery connector is not required. Martini can integrate using Beamery’s confirmed native REST APIs, provisioned authentication methods, and—where available and appropriate—webhook or event-notification endpoints.

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

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

Which Beamery integration methods should be used?

REST APIs are the recommended and primary method. Webhook-style notifications can be used for selected events only after tenant coverage is confirmed. GraphQL, SOAP, general bulk APIs, public attachment APIs, and direct database access were not confirmed and should not be assumed.

Can Martini receive Beamery webhooks or event notifications?

Martini can expose an API endpoint or workflow trigger capable of receiving HTTP notifications. Beamery’s available event types, object coverage, authentication requirements, and delivery behavior must be verified for the customer’s tenant before relying on this pattern.

How does synchronization with Beamery handle large data sets?

Use documented pagination, incremental filters, controlled scheduling, durable checkpoints, and limited concurrency. Because a general Beamery bulk API was not confirmed, integrations should not assume bulk export behavior. Idempotent target writes and reconciliation help manage interrupted or overlapping runs.

How are Beamery fields, Tags, errors, and duplicates handled?

Martini can map Beamery fields and Tags to a canonical and target model, validate configured values, minimize sensitive data, and route invalid records for review. Workflows can classify authentication, authorization, rate-limit, validation, and server errors, retry transient failures with bounded backoff, and use Beamery identifiers or event keys to prevent duplicates.

Related Martini documentation

Beamery APIs

Workflows

Data processing

Security

Operations

Plan your Beamery integration

Use Martini to connect Beamery’s APIs and verified event mechanisms with your enterprise systems through secure, observable, and maintainable workflows.

EXPLORE MARTINI
BOOK A DEMO