Ellipse Gradient for Header

Lattice Integration Guide

Integrate Lattice people-management data with enterprise systems through its REST API, bearer-token authentication, and Martini workflows.

Lattice integration options at a glance

Lattice provides a public REST API for programmatic access to selected Users, Teams, Goals, Reviews, Feedback, and other product data. API requests use an administrator-created API key supplied as a bearer token, with access controlled by the creating user’s permissions. Martini can consume these endpoints in scheduled or API-triggered workflows, paginate through collections, maintain synchronization checkpoints, and map Lattice JSON into HRIS, directory, analytics, collaboration, or operational systems. A generally available webhook framework, public GraphQL API, SOAP API, bulk API, direct database access, and general-purpose file API were not confirmed, so event-driven and high-volume designs should be validated against the required Lattice module and may require scheduled REST polling.

Integration pointSupported by Lattice?Common use casesHow Martini supports it
REST APIsYesAccess selected Lattice Users, Teams, Goals, Reviews, Feedback, and other product resources for employee synchronization, reporting, and workflow automation.Martini can consume Lattice REST endpoints, handle JSON responses, paginate collections, transform fields, and orchestrate writes to downstream systems.
AuthenticationYesLattice public API requests use an administrator-created API key supplied as a bearer token in the Authorization header.Martini can store the API key in Secrets Management or secure environment configuration and apply it to REST requests without embedding it in workflow logic.
Webhooks / outbound callbacksNot confirmedA generally available webhook framework covering all Lattice object changes was not confirmed. Selected event or notification capabilities may require product-specific validation.Martini can receive webhook-style notifications when Lattice documents the required event and endpoint behavior; otherwise it can use scheduled polling and reconciliation.
Bulk / async / batch APIsNot confirmedA distinct public bulk or asynchronous API was not confirmed. Large synchronizations should use documented REST pagination, filtering, and rate-limit behavior.Martini can divide work into scheduled batches, maintain checkpoints, throttle requests, and retry transient failures without assuming a bulk endpoint.
GraphQL APIsNot confirmedA public Lattice GraphQL API was not confirmed in the supplied documentation.Martini supports GraphQL consumption generally, but Lattice integrations should use the documented REST API unless a Lattice GraphQL API is separately confirmed.
SOAP APIsNoA public Lattice SOAP API was not confirmed.Martini can consume SOAP services generally, but SOAP should not be used as the Lattice integration method without a confirmed Lattice endpoint.
File / attachment APIsNot confirmedA general-purpose public file or attachment API was not confirmed, although particular Lattice modules may support documents or supporting content.Martini can process files when a documented Lattice export or endpoint is available, but the integration should not assume general attachment access.
Database / analytics accessNoDirect database, SQL, and public analytics warehouse access were not confirmed for Lattice.Martini should consume Lattice APIs or documented exports and can write normalized results to approved databases or analytics platforms.

How Lattice exposes data and business events

Lattice REST APIs

Lattice’s public REST API is the primary confirmed mechanism for programmatic access to selected business resources. It can support employee-data exchange, scheduled synchronization, reporting, and workflow-driven updates, subject to tenant permissions, product modules, pagination, and documented endpoint availability.

Martini implementation pattern

Martini implementation pattern: Martini authenticates with a Lattice API key stored as a secret, invokes the required REST endpoints, retrieves all pages, validates and transforms JSON payloads, applies business rules, and writes approved data to downstream systems. A checkpoint or reconciliation process controls incremental and repeat processing.

Implementation sequence

Load the Lattice API key from secure environment configuration
Invoke the documented Lattice REST endpoint
Continue through all available result pages
Validate the response and required object fields
Map Lattice JSON to the canonical data model
Apply privacy, ownership, and deactivation rules

Scheduled REST synchronization

Because a general-purpose webhook framework and distinct bulk API were not confirmed, scheduled polling is a practical pattern for detecting changes in Users, Teams, Goals, Reviews, and other supported resources.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow at an appropriate interval, the workflow uses documented filters or timestamps where available, stores a checkpoint, processes pages in bounded batches, and periodically performs reconciliation when incremental change detection is incomplete.

Implementation sequence

Start the workflow on a defined schedule
Read the last successful synchronization checkpoint
Request filtered or paginated Lattice resources
Transform and process each page
Persist the new checkpoint after successful processing
Retry transient failures and reconcile missed changes

Lattice webhook-style notifications

Lattice webhook or callback coverage for selected events may exist in particular products or configurations, but a generally available framework covering all object changes was not confirmed.

Martini implementation pattern

Martini implementation pattern: first verify that the required Lattice event, payload, authentication behavior, and delivery guarantees are documented. If confirmed, Martini receives the notification, validates it, retrieves the current resource when necessary, and invokes the same reusable processing workflow used by polling.

Implementation sequence

Confirm the required Lattice event and delivery behavior
Receive the notification through a Martini API or workflow entry point
Validate the event and deduplicate its identifier
Retrieve the current Lattice resource when the payload is incomplete
Apply mappings and business rules
Record the outcome and retry eligible failures

Common Lattice integration patterns

Pattern 1: Synchronize employees from an HRIS to Lattice

When to use this pattern

Use this pattern when Workday, BambooHR, ADP Workforce Now, or Rippling remains authoritative for employee identity and employment information while Lattice requires current Users and Teams. It separates source ownership from downstream people-management updates and prevents circular synchronization.

Integration direction
Workday
Martini
Lattice
Example Mapping
Lattice FieldCanonical FieldTarget Field
employeeIdemployee.externalIdUser external identifier
managerIdemployee.managerExternalIdUser manager reference
departmentorganization.departmentTeam or department association
employmentStatusemployee.statusUser active or inactive state
Martini implementation pattern

A scheduled Martini workflow reads changed HRIS employees, normalizes identifiers, validates required attributes, maps them to Lattice Users and Teams, and applies create, update, or deactivation rules. Stable keys make retries idempotent; rejected records are isolated with request context and processed again after correction.

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

Pattern 2: Publish Lattice organization data to reporting

When to use this pattern

Use this pattern when reporting or analytics platforms need current Users, Teams, manager relationships, or approved performance metadata without directly accessing Lattice. It is appropriate when downstream reporting requires a normalized model and controlled handling of sensitive employee data.

Integration direction
Lattice
Martini
Data warehouse
Example Mapping
Lattice FieldCanonical FieldTarget Field
idperson.latticeIdperson_source_id
teamIdorganization.teamIdteam_source_id
managerIdorganization.managerIdmanager_source_id
statusperson.lifecycleStatusemployment_status
Martini implementation pattern

Martini retrieves paginated Lattice resources on a schedule, filters fields to the approved reporting contract, converts values into warehouse types, and writes batches using stable source identifiers. Checkpoints, periodic reconciliation, and privacy-aware logging limit duplicates and accidental exposure.

Martini capabilities used
  • scheduler trigger
  • REST API consumption
  • JSON handling
  • mapping and transformation
  • field filtering
  • checkpoint and retry logic

Pattern 3: Deliver approved Lattice updates to collaboration tools

When to use this pattern

Use this pattern for reminders or notifications based on approved Goals, Reviews, Feedback, or User status data. It should be used only when the notification audience and content are explicitly defined, because performance and feedback information can be sensitive.

Integration direction
Lattice
Martini
Slack
Example Mapping
Lattice FieldCanonical FieldTarget Field
goalStatuspeopleProcess.statusmessage.status
userNameemployee.displayNamemessage.recipient
reviewCycleNamereview.cycleNamemessage.context
dueDatepeopleProcess.dueDatemessage.deadline
Martini implementation pattern

A scheduled workflow or confirmed Lattice event starts Martini processing. The workflow retrieves current data, excludes private content, evaluates notification rules, formats a Slack or Teams message, and records a delivery key so a retry does not send duplicates.

Martini capabilities used
  • workflow orchestration
  • REST API consumption
  • business rules
  • data transformation
  • privacy filtering
  • idempotency and error handling

Pattern 4: Synchronize Lattice performance data to analytics

When to use this pattern

Use this pattern when approved Goals, Reviews, Feedback, Competencies, or User metadata must be analyzed outside Lattice. It is suitable for aggregate or metadata reporting and should not replicate full review comments or feedback text unless there is a documented business requirement.

Integration direction
Lattice
Martini
Analytics platform
Example Mapping
Lattice FieldCanonical FieldTarget Field
goalIdperformance.goalIdgoal_source_id
reviewIdperformance.reviewIdreview_source_id
competencyIdperformance.competencyIdcompetency_source_id
statusperformance.lifecycleStatusstatus
Martini implementation pattern

Martini uses paginated REST reads, applies tenant and field-level access rules, transforms module-specific values into an approved analytics schema, and writes results with source identifiers and load timestamps. Rate-limit responses are delayed and retried, while permission and schema errors are surfaced for review.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • privacy and access rules
  • rate-limit handling
  • monitoring and error handling

Applications commonly integrated with Lattice

Lattice data is commonly coordinated with HR, identity, collaboration, and operational applications. Martini can orchestrate these flows while preserving clear ownership for employee, organizational, performance, and notification data.

Application Scenario Direction Martini Pattern
Workday Keep employee profiles, managers, departments, and employment status aligned while Workday remains the principal HR system of record. Workday → Martini → Lattice Schedule a workflow to read changed Workday workers, map identity and organization attributes to Lattice Users and Teams, apply create or update rules, and record rejected or retried items. Selected Lattice data can flow back through a separate reporting workflow.
BambooHR Synchronize employee and organizational data from BambooHR into Lattice for people-management processes. BambooHR → Martini → Lattice Consume BambooHR and Lattice REST endpoints, normalize employee identifiers and manager relationships, validate required fields, then upsert Lattice Users and Teams with checkpointing and error handling.
ADP Workforce Now Connect workforce records and employment changes with Lattice employee profiles. ADP Workforce Now → Martini → Lattice Use a scheduled workflow to retrieve approved workforce changes, transform ADP fields into Lattice’s user model, apply deactivation and duplicate-prevention rules, and route permission or validation failures for review.
Rippling Coordinate employee lifecycle data between the HR, IT, and people-management platforms. Rippling → Martini → Lattice Orchestrate lifecycle reads from Rippling, map employment and team attributes to Lattice Users, and use stable external identifiers, retries, and reconciliation to keep changes consistent.
Okta Support identity lifecycle, single sign-on, and provisioning processes around Lattice user accounts where the relevant product configuration is enabled. Okta → Martini → Lattice Use Martini to coordinate approved identity or provisioning data with Lattice API operations, keeping authentication and provisioning concerns separate and validating the exact Okta and Lattice scopes before deployment.
Slack Deliver employee, goal, feedback, or review-related notifications to collaboration channels. Lattice → Martini → Slack Poll documented Lattice endpoints or consume a confirmed event source, filter for approved statuses, transform the result into a concise notification, and send it to Slack while excluding sensitive review or feedback content.
Microsoft Teams Deliver people-process notifications and reminders to employees and managers. Lattice → Martini → Microsoft Teams Run a scheduled or API-triggered workflow that retrieves eligible Lattice data, applies privacy and audience rules, formats a Teams message, and records delivery outcomes for retry or reconciliation.
Jira Create or update work items when approved people-process events require operational follow-up. Lattice → Martini → Jira Retrieve relevant Lattice status or lifecycle data, apply business rules that determine whether a Jira issue is required, map the approved fields, and use an idempotency key to avoid duplicate issues.

How to build a Lattice integration in Martini

Objective

Establish a controlled connection to Lattice and any target systems without placing credentials in workflow constants.

Instructions in Martini

  • Create or obtain a Lattice API key with the minimum required permissions
  • Store the bearer token in Martini Secrets Management or secure environment configuration
  • Configure REST authentication and separate development, test, and production credentials
  • Confirm the enabled Lattice modules and accessible object fields

Objective

Select a trigger that matches Lattice’s confirmed integration behavior and the required freshness of the data.

Instructions in Martini

  • Use a scheduler for recurring synchronization and polling
  • Use an API-triggered Martini workflow when another system initiates processing
  • Use a Lattice notification only after the required event and delivery behavior are confirmed
  • Define checkpoint and reconciliation behavior before implementation

Objective

Read the required Lattice resources reliably while accounting for pagination, permissions, and tenant-specific availability.

Instructions in Martini

  • Call the documented Lattice REST endpoints
  • Request only fields required by the integration
  • Continue through paginated responses until all required results are processed
  • Capture stable Lattice identifiers and relevant update markers
  • Treat permission, validation, rate-limit, and transient server responses differently

Objective

Coordinate retrieval, transformation, business rules, target writes, and processing state in a maintainable Martini workflow.

Instructions in Martini

  • Separate source retrieval from target delivery where the flow benefits from reuse
  • Use bounded batches for larger synchronizations
  • Maintain a checkpoint only after successful processing
  • Route rejected objects to an operational review path
  • Reuse the same processing logic for polling and confirmed event notifications

Objective

Convert Lattice JSON and module-specific fields into a canonical model understood by downstream applications.

Instructions in Martini

  • Map Users, Teams, Goals, Reviews, Feedback, or Competencies to explicit canonical fields
  • Normalize identifiers, dates, statuses, and manager relationships
  • Filter private review and feedback content unless expressly required
  • Validate required fields and expected enum values
  • Apply field-level transformations before writing to the target

Objective

Ensure that ownership, privacy, lifecycle, and duplicate-prevention decisions are explicit before data leaves Martini.

Instructions in Martini

  • Define whether Lattice or another system owns each field
  • Use stable Lattice identifiers for idempotent create and update behavior
  • Handle new, changed, inactive, removed, and anonymized objects separately
  • Apply audience and retention rules to sensitive performance data
  • Prevent circular updates between Lattice and HRIS systems

Common Lattice data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
UsersSynchronize employee identity, employment status, manager relationships, and other people attributes.Workday, BambooHR, ADP Workforce Now, Rippling, Okta, data warehousesMartini retrieves Users through REST workflows, applies field-level filtering and stable-key upsert rules, and handles pagination, deactivation, permissions, and retries.
TeamsRepresent departments, reporting groups, and organizational structures used by Lattice.HRIS platforms, identity platforms, reporting databases, analytics systemsMartini maps Teams and relationships into a canonical organization model, validates parent or manager references, and reconciles changes on a schedule.
GoalsShare individual, team, or company objectives and progress with approved reporting or notification processes.Analytics platforms, Slack, Microsoft Teams, reporting applicationsMartini retrieves only required goal fields, transforms status and ownership values, applies privacy rules, and routes approved summaries to target systems.
ReviewsCoordinate performance review cycles, subjects, statuses, and approved review-related reporting data.Analytics platforms, HR reporting systems, workflow applicationsMartini filters sensitive fields, maps review-cycle metadata, enforces access and retention rules, and avoids replicating private content unless explicitly required.
FeedbackSupport approved reporting or employee-process workflows involving feedback submitted about or by employees.Analytics platforms, collaboration tools, HR reporting systemsMartini treats Feedback as sensitive, applies field-level filtering and authorization rules, and uses idempotent writes with audit-friendly processing results.
CompetenciesRepresent skills, behaviors, or evaluation criteria associated with performance management.Reporting platforms, learning or development applications, HR data storesMartini normalizes competency identifiers and values, maps them to downstream schemas, and handles module-specific availability and enum changes conservatively.

Authentication and security considerations

Bearer-token authentication

Lattice public API requests use an administrator-created API key supplied in the Authorization header as a bearer token. Access depends on the permissions of the user or administrator who created the key.

Secrets and least privilege

Store Lattice API keys in Martini Secrets Management or secure environment configuration. Use separate credentials for development and production, rotate and revoke keys through an accountable ownership process, and request only the permissions required by each workflow.

Sensitive people data

Reviews, Feedback, compensation-related information, engagement data, and employee attributes may be confidential. Filter fields before transmission, restrict target access, and avoid logging API keys or sensitive employee content.

Operational considerations for Lattice integrations

Pagination and volume

Do not assume one response contains all Users, Teams, Goals, or Reviews. Process documented pages in bounded batches and confirm current Lattice rate limits and response headers before sizing a large synchronization.

Incremental processing

Use documented timestamps, filters, or update markers where available. If reliable incremental filtering is unavailable, maintain a Martini checkpoint and run periodic reconciliation to detect missed, removed, or deactivated objects.

Idempotency and retries

Use stable Lattice identifiers as external keys. Separate create, update, deactivation, and removal behavior, and apply backoff for rate-limit or transient server responses. Avoid duplicate notifications or Users when a timeout occurs after a target write.

Schema and module differences

Available fields, required values, and object access can vary by enabled Lattice product modules and tenant permissions. Test pagination boundaries, manager and team changes, status transitions, permission failures, and schema changes before production rollout.

Event uncertainty

Validate any required webhook or callback event and its delivery guarantees. If the event is not confirmed, use scheduled polling with checkpoints and reconciliation rather than assuming real-time coverage.

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

Centralized orchestration

Martini coordinates Lattice API calls, target-system writes, business rules, checkpoints, retries, and monitoring in workflows instead of scattering logic across scripts.

Reusable integration assets

REST consumption, mappings, validation, privacy filtering, and error-handling logic can be structured for reuse across HRIS, reporting, collaboration, and operational integrations.

Controlled change management

Environment configuration and Secrets Management keep credentials separate from implementation logic, while explicit mappings and rules make Lattice module and schema changes easier to test and govern.

Flexible integration boundaries

Martini can consume Lattice APIs, expose REST APIs for surrounding systems, and connect the resulting workflows to other APIs, databases, files, or messaging systems without requiring a dedicated Lattice connector.

Frequently asked questions

How can Lattice be integrated with enterprise systems?

Lattice can be integrated through its public REST API using administrator-created API keys supplied as bearer tokens. Enterprise workflows can retrieve and update supported Lattice resources, paginate through collections, synchronize employee and organizational data, and publish approved performance or people-process data to downstream systems. A general-purpose webhook framework, public GraphQL API, SOAP API, bulk API, and direct database access were not confirmed.

Can Martini integrate with Lattice?

Yes. Martini can consume the Lattice REST API, authenticate with a securely stored bearer-token API key, orchestrate scheduled or API-triggered workflows, transform Lattice JSON, and deliver approved data to HRIS, identity, analytics, collaboration, or operational systems. A native Martini Lattice connector is not documented in the supplied information.

Do I need a connector to integrate Lattice with Martini?

No. A dedicated Lattice connector is not required. Martini can integrate using Lattice’s confirmed REST API and bearer-token authentication, with webhook-style notifications used only if the required Lattice event is specifically documented and available.

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

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

Which Lattice integration methods should architects use?

The documented and recommended method is the Lattice REST API with bearer-token API-key authentication. Use scheduled, paginated REST synchronization for recurring exchanges. Webhook or callback designs require confirmation of the specific event and tenant behavior. A public GraphQL API, SOAP API, distinct bulk API, general file API, and direct database access were not confirmed.

Are Lattice webhooks or real-time events available?

A generally available webhook framework covering changes to all Lattice objects was not confirmed. Selected event or notification capabilities may exist for particular products or use cases, but the required event must be validated. When it is unavailable, Martini can use scheduled polling, checkpoints, and reconciliation workflows.

How does Martini synchronize Lattice data and handle mapping?

Martini can retrieve paginated Lattice Users, Teams, Goals, Reviews, Feedback, Competencies, or other supported resources, map them into a canonical model, apply privacy and ownership rules, and write them to target systems. Stable Lattice identifiers, checkpoints, update filters where documented, and periodic reconciliation help prevent duplicates and missed changes.

How does Martini handle Lattice errors, retries, duplicates, and API exposure?

Martini can distinguish authentication, permission, validation, rate-limit, and transient server errors, then apply appropriate logging, retry, delay, and escalation behavior. Stable identifiers and idempotent upsert logic reduce duplicate Users or downstream notifications. Martini can also expose REST APIs for surrounding systems to initiate or access controlled integration workflows.

Related Martini documentation

API Integration

Workflows

Data and Security

Operations

Integrate Lattice with Martini

Use Martini to connect Lattice REST APIs with HR, identity, analytics, collaboration, and operational systems through secure workflows, explicit mappings, and reliable synchronization controls.

EXPLORE MARTINI
BOOK A DEMO