Ellipse Gradient for Header

1Password Integration Guide

Connect 1Password vaults, secrets, files, account events, and identity provisioning flows with enterprise systems through REST APIs, polling, SCIM, and Martini workflows.

1Password integration options at a glance

1Password Connect provides the primary REST API for accessing supported vaults, items, item fields, and attached files. Service accounts and Secrets Automation provide scoped machine access for runtime secret retrieval and automation. The Events API supports cursor-based polling of account activity, making it suitable for incremental audit and governance workflows rather than universal webhooks. The SCIM Bridge provides a separate interface for provisioning users and groups from an identity provider. Martini can consume these APIs, store cursors and protected tokens, map item or event data, expose controlled APIs, and orchestrate validation, retries, filtering, and downstream updates.

Integration pointSupported by 1Password?Common use casesHow Martini supports it
REST APIsYes1Password Connect exposes REST endpoints for supported vault, item, item field, and file operations. It is the primary interface for application secret retrieval and controlled resource management.Martini can consume the Connect API from workflows, apply mappings and validation, and expose a controlled Martini API façade for internal consumers.
Events APIYesThe Events API provides account activity and supports incremental retrieval using a cursor. It is useful for audit, governance, and selected synchronization scenarios.Martini can schedule polling workflows, persist the last successful cursor, process events idempotently, and forward transformed activity to downstream systems.
Webhooks / outbound callbacksLimited1Password event delivery is documented as API retrieval and cursor-based polling rather than a universal outbound webhook stream. Coverage depends on supported event types.Martini can use scheduled polling for the Events API; webhook-style Martini endpoints are applicable only where a separately confirmed callback source exists.
File / attachment APIsYes1Password Connect supports operations for files attached to items, including supported metadata and content operations subject to permissions.Martini can retrieve, validate, transform, and forward supported attachments while treating files and error payloads as sensitive data.
SCIM provisioningYesThe SCIM Bridge supports user and group provisioning from an identity provider into 1Password Business accounts.Martini can orchestrate related requests, transform attributes, validate provisioning data, and route audit or downstream synchronization events.
AuthenticationYesConnect and service accounts use scoped bearer tokens. The SCIM Bridge uses a separately configured bearer token for identity provisioning.Martini can store tokens in protected configuration or secrets management and inject them into requests without embedding credentials in mappings or logs.
SDKs and client librariesYes1Password provides developer tooling and SDKs for supported scenarios, but the documented REST interfaces are sufficient for many integrations.Martini can consume the REST APIs directly, avoiding a dependency on a dedicated SDK when the required operation is available through an API endpoint.
GraphQL APIsNot confirmedNo official 1Password GraphQL API was identified in the supplied research.Martini can consume GraphQL generally, but a 1Password integration should use the confirmed REST, Events, or SCIM surfaces instead.

How 1Password exposes data and business events

1Password Connect REST APIs

1Password Connect exposes REST endpoints for supported vaults, items, item fields, and attached files. Access is controlled by the Connect server configuration, token permissions, and the vaults made available to the service.

Martini implementation pattern

Martini implementation pattern: a workflow or Martini API receives a request, validates the permitted vault and item reference, calls Connect with a scoped bearer token, filters and maps the response, and returns or writes only the required data.

Implementation sequence

Receive an authenticated request or workflow input
Resolve and validate the permitted vault and item
Call the Connect REST API with a scoped bearer token
Validate the item category and required fields
Map and filter only the required values
Write the result or return a controlled response without logging secrets

1Password Events API

The Events API exposes supported account activity through incremental retrieval with a cursor. It should be treated as a polling interface, not as a universal webhook stream or guaranteed real-time feed.

Martini implementation pattern

Martini implementation pattern: a scheduled workflow reads the stored cursor, requests new activity, processes each event idempotently, forwards suitable events to a governance or monitoring target, and persists the new cursor only after successful downstream handling.

Implementation sequence

Start a scheduled polling workflow
Read the last successfully stored event cursor
Request the next page or range of supported events
Transform and deduplicate event activity
Send approved events to the downstream system
Persist the cursor after successful processing

1Password File and Attachment APIs

Connect supports file-related operations for files attached to items, subject to endpoint support, vault permissions, and token scope. Attachments may contain sensitive information even when their metadata appears non-sensitive.

Martini implementation pattern

Martini implementation pattern: a workflow resolves the parent item, retrieves supported file metadata or content, applies size and security checks, and transfers the attachment to an approved destination without exposing it in logs.

Implementation sequence

Receive an approved item and file reference
Validate vault, item, file, and token permissions
Retrieve supported file metadata or content
Apply content, size, and destination checks
Map metadata and transfer the attachment
Record non-sensitive processing status

1Password SCIM Bridge

The SCIM Bridge provides a separate integration surface for provisioning users and groups from an identity provider. It uses its own bearer token and object model and should be operated independently from Connect-based secret retrieval.

Martini implementation pattern

Martini implementation pattern: Martini can sit around SCIM-related orchestration to validate identity attributes, transform requests where needed, forward audit information, and coordinate downstream actions while keeping SCIM credentials separate.

Implementation sequence

Receive or observe a validated identity lifecycle request
Validate user or group identifiers and required attributes
Transform the request to the required SCIM representation
Send or orchestrate the SCIM operation
Process the response and classify failures
Forward audit information without exposing credentials

Common 1Password integration patterns

Pattern 1: Provide application secrets through a controlled API

When to use this pattern

Use this pattern when an internal application or delivery process needs a specific secret but should not receive unrestricted access to a 1Password vault or complete item payload.

Integration direction
Application
Martini
1Password Connect
Example Mapping
1Password FieldCanonical FieldTarget Field
vault.idsecretVaultIdConnect vault reference
item.idsecretReferenceConnect item reference
fields[].labelrequestedFieldFiltered application field
fields[].valuesecretValueApplication response value
Martini implementation pattern

Expose a protected Martini API that accepts an approved secret reference, validates authorization and allowlists, calls Connect with a scoped bearer token, filters the requested fields, and returns only the required values. Apply timeout and retry rules while ensuring secret values, authorization headers, and complete item responses are not logged.

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

Pattern 2: Synchronize selected configuration metadata

When to use this pattern

Use this pattern when teams need to synchronize ownership, references, expiration metadata, or selected configuration values from 1Password without broadly copying sensitive secret material.

Integration direction
1Password Connect
Martini
Configuration platform
Example Mapping
1Password FieldCanonical FieldTarget Field
item.idsourceItemIdExternal configuration key
item.titleconfigurationNameName
item.categorysecretTypeType
item.vault.idsourceVaultIdVault reference
Martini implementation pattern

Schedule a Martini workflow to retrieve approved items, validate category and field structure, map non-sensitive metadata to the target schema, and perform idempotent upserts. Transfer secret values only when explicitly required, and use stable item identifiers to avoid duplicate target objects.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • validation
  • business rules
  • idempotent upserts
  • error handling

Pattern 3: Process account events for audit and governance

When to use this pattern

Use this pattern when security or operations teams need selected 1Password activity delivered to monitoring, governance, or ticketing systems with incremental processing.

Integration direction
1Password Events API
Martini
Datadog
Example Mapping
1Password FieldCanonical FieldTarget Field
event.idactivityIdevent identifier
event.typeactivityTypeevent type
event.actoractorReferenceuser or actor
event.timestampoccurredAtevent timestamp
Martini implementation pattern

Run a scheduled workflow that reads the last successful cursor, retrieves supported events, validates and deduplicates activity, maps it to the target telemetry model, and advances the cursor only after successful delivery. Handle cursor invalidation, temporary API failures, and downstream retries without reprocessing the same activity unnecessarily.

Martini capabilities used
  • scheduler triggers
  • workflows
  • API consumption
  • cursor persistence
  • data mapping
  • deduplication
  • retry handling

Pattern 4: Orchestrate identity provisioning through SCIM

When to use this pattern

Use this pattern when an identity provider provisions or deprovisions 1Password users and groups and additional validation, audit forwarding, or downstream synchronization is needed.

Integration direction
Okta
Martini
1Password SCIM Bridge
Example Mapping
1Password FieldCanonical FieldTarget Field
user.userNameidentityNameSCIM userName
user.activelifecycleStatusSCIM active
group.displayNamegroupNameSCIM displayName
group.membersmembershipListSCIM members
Martini implementation pattern

Use Martini to validate and transform identity lifecycle data around the SCIM process, apply business rules for required attributes, route failures for review, and publish non-sensitive audit information. Keep SCIM provisioning isolated from Connect secret retrieval so failures in one domain do not trigger unintended changes in the other.

Martini capabilities used
  • workflows
  • API orchestration
  • data mapping
  • validation
  • business rules
  • audit routing
  • error handling

Applications commonly integrated with 1Password

1Password can be integrated with identity, development, infrastructure, delivery, and monitoring products. The exact implementation depends on the selected 1Password interface, token scope, and the capabilities enabled in the target product.

Application Scenario Direction Martini Pattern
Okta Synchronize workforce users and groups through the 1Password SCIM Bridge while centralizing identity lifecycle management in Okta. Okta → 1Password Use Martini to orchestrate or audit SCIM-related provisioning, transform identity attributes where required, and forward provisioning outcomes to downstream systems. Keep SCIM credentials separate from Connect tokens.
Microsoft Entra ID Provision and deprovision 1Password users and groups from a centrally managed workforce identity directory. Microsoft Entra ID → 1Password Coordinate SCIM provisioning flows and related audit processing with Martini workflows, applying validation and controlled field mappings before forwarding identity changes.
GitHub Provide repository, deployment, or automation credentials to development and CI/CD processes without embedding secrets in source repositories. 1Password → Martini → GitHub Expose a protected Martini API or workflow that retrieves only approved fields from Connect or Secrets Automation and returns a narrowly scoped response to GitHub-based automation without logging secret values.
GitLab Supply protected configuration and deployment credentials to GitLab CI/CD jobs while retaining centralized vault access controls. 1Password → Martini → GitLab Use a Martini workflow to authenticate with a scoped service-account or Connect token, validate the requested secret reference, filter fields, and deliver only the values required by the pipeline.
Kubernetes Retrieve application secrets at deployment or runtime while keeping sensitive values outside manifests and application repositories. 1Password → Martini → Kubernetes Orchestrate secret retrieval through Martini, validate vault and item permissions, transform the result into the required deployment payload, and prevent complete item data from entering logs or responses.
Terraform Provide infrastructure credentials and configuration values during provisioning without hard-coding them in Terraform source files. 1Password → Martini → Terraform Use Martini as a controlled retrieval and transformation layer for approved infrastructure values, with environment-specific token configuration, field filtering, validation, and retry handling.
Jenkins Make centrally managed credentials available to build and deployment jobs while preserving vault permissions and auditability. 1Password → Martini → Jenkins Expose a Martini endpoint or invoke a workflow that resolves an approved item, returns selected fields to Jenkins, and records only non-sensitive operational metadata.
Datadog Forward selected 1Password account activity to monitoring and governance processes for alerting, audit, and operational review. 1Password → Martini → Datadog Schedule a Martini workflow to poll the Events API, persist and advance the cursor after successful processing, deduplicate event identifiers, transform event payloads, and send suitable telemetry to Datadog.

How to build a 1Password integration in Martini

Objective

Establish network access to 1Password Connect or the relevant SCIM endpoint and configure environment-specific credentials without exposing them in source or workflow data.

Instructions in Martini

  • Configure the required Connect, service-account, or SCIM bearer token in protected Martini configuration
  • Restrict each token to the vaults, operations, or identity scope required by the workflow
  • Validate TLS, routing, DNS, firewall, and Connect health requirements

Objective

Select an API request, scheduled workflow, or identity lifecycle input based on the required latency and the 1Password interface being used.

Instructions in Martini

  • Use a Martini API for controlled on-demand secret retrieval
  • Use a scheduler for Events API cursor polling or scheduled synchronization
  • Use an identity-provider-driven flow for SCIM provisioning scenarios
  • Do not treat the Events API as a universal webhook stream

Objective

Call the appropriate 1Password interface and retrieve only the vault, item, file, event, user, or group data required by the business process.

Instructions in Martini

  • Validate references and permissions before calling Connect
  • Handle pagination for list and event responses
  • Store and read the Events API cursor safely
  • Treat item fields, file contents, tokens, and response bodies as sensitive

Objective

Coordinate API calls, validation, conditional routing, downstream writes, and recovery behavior in a maintainable Martini workflow.

Instructions in Martini

  • Separate Connect, Events API, and SCIM concerns
  • Apply business rules for permitted vaults, item categories, and target destinations
  • Use reusable workflow logic where multiple consumers follow the same access policy
  • Prevent concurrent pollers from sharing an uncontrolled cursor

Objective

Convert 1Password objects and activity payloads into the target system model while handling item category variation and optional fields.

Instructions in Martini

  • Map only approved item fields to target properties
  • Validate required fields and tolerate missing optional or custom fields
  • Preserve stable item or event identifiers for correlation
  • Filter secrets before logging, forwarding, or returning responses

Objective

Deliver the transformed result to the target application, monitoring platform, configuration store, or identity process using deterministic behavior.

Instructions in Martini

  • Prefer idempotent upserts for synchronization workflows
  • Forward only approved event activity to governance or monitoring targets
  • Transfer attachments only when required and authorized
  • Do not copy secret values broadly when a reference or metadata is sufficient

Common 1Password data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
VaultsOrganize secrets and control which collections are available to an integration.Applications, Kubernetes, GitHub, GitLab, Terraform, JenkinsMartini validates the permitted vault reference and applies environment-specific access rules before retrieving or updating supported resources.
ItemsStore Login, Password, API Credential, Secure Note, server credential, and other secret records.CI/CD platforms, applications, infrastructure tooling, internal APIsMartini retrieves only approved items, validates the category and required fields, filters sensitive values, and uses deterministic references for idempotent processing.
Item fieldsRepresent usernames, passwords, URLs, notes, and custom fields within an item.Application configuration, deployment pipelines, infrastructure automationMartini maps selected fields to target schemas, handles optional or custom fields cautiously, and prevents unnecessary values from appearing in logs or responses.
FilesStore attachments associated with 1Password items, including potentially sensitive supporting files.Document stores, deployment processes, internal applicationsMartini can retrieve supported metadata or content, apply permission and size checks, and forward files only when the business flow requires them.
UsersRepresent 1Password account members and identity lifecycle subjects.Okta, Microsoft Entra ID, audit platformsMartini can transform, validate, audit, or route user-related SCIM and Events API data without conflating identity provisioning with secret retrieval.
GroupsManage access-related membership and provision groups through the SCIM Bridge.Okta, Microsoft Entra ID, governance platformsMartini can orchestrate or audit group changes, preserve source identifiers, and apply separate SCIM credentials and validation rules.

Authentication and security considerations

Scoped bearer authentication

1Password Connect and service accounts use bearer tokens. Connect access is constrained by the vaults available to the Connect server and the permissions assigned to the token. The SCIM Bridge uses a separately configured bearer token.

Protect credentials and secret values

  • Store Connect, service-account, and SCIM tokens in protected Martini configuration or secrets management.
  • Use separate tokens for environments and workloads where practical.
  • Do not embed credentials in mappings, source code, request payloads, or logs.
  • Filter item fields before returning data and treat attachments as sensitive.

Network and deployment controls

For self-hosted Connect deployments, plan TLS validation, private routing, firewall allowlists, DNS, health monitoring, and separation of development, test, and production instances.

Operational considerations for 1Password integrations

Pagination and response size

List and event responses may require pagination. Workflows should follow the documented response model and use suitable memory and timeout settings for large items or files.

Cursor and duplicate management

Persist the Events API cursor only after successful downstream processing. Use stable event or item identifiers, deterministic upserts, and coordination between pollers to avoid duplicate or lost processing.

Retries and availability

Account for throttling, timeouts, temporary Connect unavailability, retryable HTTP responses, and backoff. Monitor Connect health and define recovery behavior for invalid or expired cursors.

Schema and testing

Item categories, custom fields, event payloads, file behavior, permissions, and SCIM responses can vary. Validate required fields, tolerate optional values, test representative item types, and review current 1Password documentation before depending on specific event coverage.

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

Orchestrate more than an API call

Scripts can retrieve a secret or poll an endpoint, but Martini provides a maintainable workflow for authentication, validation, field filtering, mapping, business rules, downstream writes, retries, and monitoring.

Protect sensitive data by design

Martini can centralize environment-specific credentials, expose controlled API façades, and enforce rules that return only approved fields instead of distributing broad vault access to every consumer.

Separate integration concerns

Connect secret retrieval, Events API polling, file handling, and SCIM provisioning use different models and controls. Martini workflows keep these concerns explicit while allowing reusable orchestration and consistent operational handling.

Reduce point-to-point coupling

A canonical mapping and workflow layer allows target systems to change without rewriting every 1Password interaction. The same integration assets can support on-demand retrieval, scheduled synchronization, audit processing, and identity-related workflows.

Frequently asked questions

How can 1Password be integrated with enterprise systems?

1Password can integrate through 1Password Connect REST APIs, service accounts and Secrets Automation, the cursor-based Events API, file and attachment operations, and the SCIM Bridge for user and group provisioning. Enterprise workflows can retrieve selected secrets, process account activity, synchronize approved metadata, or orchestrate identity lifecycle operations.

Can Martini integrate with 1Password?

Yes. Martini can consume the 1Password Connect REST API, poll the Events API on a schedule, handle supported file operations, and orchestrate SCIM-related requests. It can provide mapping, validation, field filtering, retries, and controlled API façades without requiring a documented native Martini connector.

Do I need a connector to integrate 1Password with Martini?

No. A dedicated 1Password connector is not required. Martini can use 1Password's confirmed native integration mechanisms, including Connect REST APIs, bearer-token authentication, Events API polling, supported file endpoints, service-account access, and SCIM interfaces.

Is there any extra Lonti cost to integrate 1Password with Martini?

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

Which 1Password integration methods should architects use?

Use 1Password Connect REST APIs for vault, item, field, and supported file access. Use service accounts or Secrets Automation for scoped machine access, the Events API for cursor-based activity polling, and the SCIM Bridge for identity provisioning. No official 1Password GraphQL or SOAP API was confirmed.

Does 1Password provide webhooks or real-time events?

The Events API provides account activity through incremental retrieval and cursors, but it should not be described as a universal webhook mechanism or guaranteed real-time stream. Martini can poll it with a scheduler at an interval appropriate to business latency and API behavior.

How does Martini synchronize 1Password data safely?

Martini can retrieve selected objects, map fields to a canonical or target model, validate item categories and required values, and perform idempotent upserts. Events API workflows should persist the cursor only after successful processing and use stable identifiers to prevent duplicate downstream actions.

How are 1Password errors, retries, and sensitive data handled?

Martini workflows can classify retryable failures, apply backoff and retry policies, validate responses, and route non-retryable errors for review. Tokens, passwords, private keys, complete item payloads, authorization headers, and sensitive files should be excluded from logs and filtered before responses or downstream writes.

Related Martini documentation

APIs

Workflows

Security

Data

Operations

Connect 1Password with Martini

Use Martini to build secure, maintainable workflows around 1Password Connect, Events API polling, file operations, and SCIM provisioning. Centralize authentication, mapping, policy enforcement, retries, and monitoring without creating point-to-point scripts.

EXPLORE MARTINI
BOOK A DEMO