Ellipse Gradient for Header

Hyland OnBase Integration Guide

Integrate OnBase documents, metadata, and content with enterprise applications through REST APIs, selected SOAP services, scheduled workflows, and controlled Martini APIs.

Hyland OnBase integration options at a glance

OnBase API Server is the primary modern integration route, with REST operations that may support document search, metadata, content retrieval, and document import depending on the release, configuration, and licensed modules. Selected SOAP and web-service interfaces may remain necessary for legacy deployments or operations not available through REST. Document content can be imported and retrieved through OnBase APIs, while batch-oriented processing is available in some configurations without a universal public bulk API. A universal webhook model was not confirmed, so Martini can use scheduled workflows for polling, checkpointing, reconciliation, mapping, validation, and controlled API exposure. Authentication may use OAuth 2.0, service identities, or enterprise authentication.

Integration pointSupported by Hyland OnBase?Common use casesHow Martini supports it
REST APIsYesOnBase API Server may provide document search, metadata access, content retrieval, document import, and related operations. Exact resources depend on the OnBase release, configuration, and licensed modules.Martini can consume the applicable OnBase REST API, map responses, paginate searches, apply business rules, and orchestrate writes to downstream systems.
SOAP APIsLimitedSOAP and web-service interfaces may support existing integrations or operations not covered by the selected REST API. Availability is version- and module-dependent.Martini can consume confirmed OnBase SOAP services, transform XML messages, handle service-specific faults, and combine SOAP calls with REST workflows.
Webhooks / outbound callbacksNot confirmedA universal OnBase webhook model for document, keyword, workflow, and content changes was not confirmed. Module-specific events or callbacks must be verified.Martini can receive a confirmed callback when the customer deployment provides one; otherwise it can use scheduled polling and checkpointing.
Bulk / async / batch processingLimitedOnBase supports batch-oriented document and import scenarios, but a universal public bulk REST API was not confirmed. Processing behavior depends on the method and configuration.Martini can orchestrate batches, validate payloads, limit concurrency, persist durable identifiers, and reconcile failed or queued documents.
File / attachment APIsYesDocument content import and retrieval are core OnBase integration requirements, including MIME type, filename, size, encoding, and metadata handling.Martini can transfer content, map metadata, validate file characteristics, separate metadata and content processing, and preserve the OnBase document identifier.
AuthenticationLimitedDepending on the interface and deployment, OnBase may use OAuth 2.0, configured service identities, Windows-integrated authentication, or other enterprise mechanisms.Martini can store endpoint credentials, tokens, certificates, and secrets as protected configuration and apply the authentication required by the confirmed OnBase interface.
Database / analytics accessNot confirmedDirect database access should not be assumed as a supported transactional integration method. Approved reporting or export interfaces should be preferred.Martini can connect to approved databases when explicitly authorized, but transactional OnBase integrations should use supported APIs rather than relying on internal schema access.

How Hyland OnBase exposes data and business events

Hyland OnBase REST APIs

OnBase API Server is the primary modern integration approach to investigate. Depending on release, configuration, and licensed modules, REST operations may expose document search, metadata, content retrieval, document import, and related functions. The exact resource model must be confirmed for the customer environment.

Martini implementation pattern

Martini consumes the confirmed OnBase REST endpoints from a workflow or exposes a controlled Martini API for callers that need OnBase access. The workflow validates authentication, retrieves or submits content, maps Document Types and Keyword Values, applies idempotency rules, and records identifiers and outcomes.

Implementation sequence

Authenticate using the confirmed OnBase API method
Receive a request or invoke the REST endpoint on a schedule
Search or retrieve the required Document and metadata
Validate Document Types, Keyword Values, permissions, and content properties
Map and transform data for the target system
Import or retrieve content through the supported OnBase operation‍‌‍‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌‍‌

Hyland OnBase SOAP and web services

OnBase has historically supported SOAP-based and other web-service interfaces, including interfaces associated with integration products such as Integration Toolkit. These services may remain necessary for existing deployments or operations that are not available through the selected REST API.

Martini implementation pattern

Martini consumes the confirmed SOAP service, handles XML request and response structures, interprets service-specific faults, and combines SOAP operations with REST, file, or downstream application steps. SOAP coverage and authentication remain dependent on the OnBase version and licensed modules.

Implementation sequence

Confirm the required SOAP service and WSDL for the OnBase deployment
Configure the approved service identity and endpoint settings
Invoke the SOAP operation from a Martini workflow
Parse the XML response or service fault
Map returned identifiers and metadata to the canonical model
Retry transient failures and route validation faults for review

Hyland OnBase document content APIs

Document content is central to OnBase integrations. Supported API operations may import or retrieve files and associate them with Document Types and Keyword Values, while exact endpoints, size limits, encoding, and synchronous or queued behavior vary by API version and configuration.

Martini implementation pattern

Martini separates metadata validation from content transfer where practical. It validates MIME type, filename, size, and business keys, transfers content through the confirmed OnBase operation, stores the returned document identifier, and prevents duplicate imports during retries.

Implementation sequence

Receive or retrieve document metadata and content
Validate file type, size, filename, and required classification
Check the source identifier or business key for an existing import
Map metadata to Document Types and Keyword Values
Submit or retrieve the document content through the supported API
Persist the OnBase document identifier and processing result

Scheduled OnBase synchronization

A universal OnBase webhook model covering all relevant document, keyword, workflow, and content changes was not confirmed. Where a supported callback is unavailable, scheduled polling is a defensible pattern for new or changed Documents.

Martini implementation pattern

Martini invokes a supported OnBase search endpoint on a schedule, filters by server-supported timestamps, identifiers, statuses, or other criteria, and persists a checkpoint after successful processing. Reconciliation and idempotency controls handle missed runs and retries.

Implementation sequence

Start the Martini workflow on a controlled schedule
Read the last successful checkpoint
Query OnBase using supported filters and pagination
Process only new or changed Documents
Apply idempotency checks before downstream writes
Store the checkpoint after successful processing and reconcile failures

Common Hyland OnBase integration patterns

Pattern 1: Synchronize OnBase documents with a customer platform

When to use this pattern

Use this pattern when Documents and their Keyword Values must be available in Salesforce or another customer platform. Scheduled polling is appropriate when no confirmed OnBase event or callback exists for the required change.

Integration direction
Hyland OnBase
Martini
Salesforce
Example Mapping
Hyland OnBase FieldCanonical FieldTarget Field
Document identifiersourceDocumentIdOnBase document reference
Document TypedocumentClassificationdocument type
Keyword ValuescustomerReferencecustomer or case reference
ContentdocumentContentfile attachment or document link
Martini implementation pattern

A scheduled Martini workflow searches OnBase for changed Documents, retrieves metadata and approved content, validates permissions and required Keywords, maps the result to Salesforce, and stores the source identifier and target reference. Checkpoints, duplicate detection, pagination, and retry handling prevent missed or repeated synchronization.

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

Pattern 2: Archive inbound documents in OnBase

When to use this pattern

Use this pattern when an external application creates documents that must be classified and retained in OnBase with reliable metadata and auditability.

Integration direction
ServiceNow
Martini
Hyland OnBase
Example Mapping
Hyland OnBase FieldCanonical FieldTarget Field
External case identifierbusinessKeyKeyword Value
Document categorydocumentClassificationDocument Type
Filename and MIME typecontentMetadatadocument content metadata
File contentdocumentContentDocument content
Martini implementation pattern

Martini exposes a controlled REST API or consumes an upstream application API, validates the required Document Type, Keywords, MIME type, and size, checks the business key for an existing import, and submits the document through the confirmed OnBase content operation. The workflow stores the returned identifier and routes validation or transient errors separately.

Martini capabilities used
  • APIs
  • workflows
  • data validation
  • data mapping
  • business rules
  • error handling

Pattern 3: Expose an OnBase document retrieval façade

When to use this pattern

Use this pattern when multiple applications need consistent, permission-aware access to selected OnBase Documents without each application implementing OnBase-specific authentication, search, and content handling.

Integration direction
Salesforce
Martini
Hyland OnBase
Example Mapping
Hyland OnBase FieldCanonical FieldTarget Field
Customer or case identifierbusinessIdentifierOnBase search criterion
Requested document categorydocumentClassificationDocument Type
OnBase Keyword ValuesdocumentMetadatanormalized response metadata
Document contentdocumentContentAPI response content
Martini implementation pattern

A Martini REST API accepts a controlled business identifier, validates caller authorization, searches OnBase through the applicable REST or SOAP interface, filters results according to business rules, retrieves approved metadata or content, and returns a normalized response. Centralized error responses and audit-safe logging keep callers independent of OnBase implementation details.

Martini capabilities used
  • API exposure
  • API consumption
  • authentication and authorization
  • mapping
  • business rules
  • error handling

Pattern 4: Process OnBase documents on a schedule

When to use this pattern

Use this pattern for records-processing, workflow-status, or reconciliation scenarios where OnBase does not provide a confirmed callback for the required event and a downstream system must be invoked for qualifying Documents.

Integration direction
Hyland OnBase
Martini
SAP
Example Mapping
Hyland OnBase FieldCanonical FieldTarget Field
Document status or modification timestampprocessingEligibilityworkflow selection rule
Document TypedocumentClassificationSAP document category
Keyword ValuesbusinessContextSAP business identifiers
Document identifiersourceDocumentIdSAP external reference
Martini implementation pattern

A scheduled Martini workflow queries OnBase using supported filters and pagination, applies eligibility and permission rules, sends qualifying data to SAP, and updates the OnBase-side state only when the required operation is confirmed. Durable checkpoints, idempotency keys, exponential backoff, and reconciliation handle interruptions and partial failures.

Martini capabilities used
  • scheduled workflows
  • API orchestration
  • pagination
  • mapping and transformation
  • business rules
  • retry and reconciliation

Applications commonly integrated with Hyland OnBase

OnBase can be integrated with business applications that create, consume, classify, or archive enterprise documents. The exact interface depends on the OnBase release, API Server configuration, licensed modules, and the target application's APIs.

Application Scenario Direction Martini Pattern
Salesforce Archive customer correspondence, contracts, forms, and case documents in OnBase while making approved document references and metadata available to Salesforce. Salesforce → Martini → Hyland OnBase Martini receives Salesforce data or scheduled changes, validates the business key and document metadata, maps fields to OnBase Document Types and Keyword Types, transfers content, and stores the returned OnBase document identifier for reconciliation.
SAP Store invoices, purchase documents, personnel records, and SAP-generated content in OnBase while returning document identifiers or processing status. SAP → Martini → Hyland OnBase A Martini workflow consumes the applicable SAP API or approved export, transforms document metadata and content, validates required OnBase Keywords, imports the document, and records identifiers and failures for retry or reconciliation.
Microsoft Dynamics 365 Archive customer, finance, and case-related documents and provide document references within Dynamics records. Microsoft Dynamics 365 → Martini → Hyland OnBase Martini orchestrates bidirectional API calls, applies Document Type and Keyword Type rules, transfers content through the supported OnBase operation, and exposes normalized document links or status to Dynamics 365.
ServiceNow Link approved OnBase documents to incidents, requests, HR cases, or other ServiceNow processes. ServiceNow → Martini → Hyland OnBase Martini consumes ServiceNow events or scheduled changes where available, validates access and metadata, imports or retrieves OnBase content, and returns document links, identifiers, or processing status to ServiceNow.
Workday Archive employee, payroll, recruiting, and compliance documents while retaining Workday business identifiers. Workday → Martini → Hyland OnBase A scheduled or API-triggered Martini workflow maps Workday identifiers to OnBase Document Types and Keyword Values, validates content and permissions, imports documents, and persists the OnBase identifier and processing outcome.
Epic Store clinical or administrative documents and associate them with patient or encounter identifiers where the healthcare deployment permits it. Epic → Martini → Hyland OnBase Martini applies healthcare-specific validation and authorization rules, maps approved identifiers to OnBase metadata, transfers content through confirmed interfaces, and avoids exposing sensitive content in operational logs.
Microsoft SharePoint Migrate or synchronize selected documents and metadata, or use OnBase as the controlled records repository. Microsoft SharePoint → Martini → Hyland OnBase Martini reads approved SharePoint content and metadata, normalizes filenames, MIME types, and business keys, applies OnBase classification rules, and performs idempotent imports or retrievals.
DocuSign Archive completed agreements and envelope metadata in OnBase for retention and retrieval. DocuSign → Martini → Hyland OnBase Martini receives confirmed DocuSign event or API data, retrieves completed content where authorized, maps envelope metadata to OnBase Keywords, validates duplicates, and imports the document with durable status tracking.

How to build a Hyland OnBase integration in Martini

Objective

Confirm the OnBase release, deployment model, API Server configuration, licensed modules, endpoints, and authentication requirements before building the workflow.

Instructions in Martini

  • Identify whether REST, SOAP, or another approved interface provides the required operation
  • Confirm OAuth 2.0, service-account, Windows-integrated, certificate, or other authentication requirements
  • Store credentials, tokens, certificates, and endpoint settings in protected Martini configuration
  • Verify permissions for Document Types, Keyword Types, folders, content, and workflow operations

Objective

Select an event-driven, API-led, or scheduled entry point based on what the OnBase deployment actually supports for the required business event.

Instructions in Martini

  • Use a confirmed OnBase callback only for the specific event it supports
  • Expose a Martini REST API when an external application initiates the transaction
  • Use a Scheduler Trigger for polling, batch processing, or reconciliation
  • Define a checkpoint and idempotency strategy before processing changes

Objective

Retrieve Documents, metadata, content, or status using supported OnBase operations while respecting pagination, search limits, and content-transfer constraints.

Instructions in Martini

  • Apply server-supported filters for identifiers, dates, statuses, or modification metadata
  • Implement explicit pagination rather than assuming the first response is complete
  • Separate metadata retrieval from large content transfers where practical
  • Preserve the OnBase document identifier and source-system business key

Objective

Coordinate OnBase calls, external application calls, transformations, business rules, and durable outcomes in a maintainable Martini workflow.

Instructions in Martini

  • Use workflow nodes to sequence API calls and conditional routes
  • Separate validation, content transfer, downstream writes, and status updates
  • Use reusable services or mappings for repeated Document and Keyword logic
  • Keep provider-specific behavior isolated from the canonical integration model

Objective

Translate source fields into OnBase Document Types, Keyword Types, Keyword Values, folders, and content metadata with explicit validation.

Instructions in Martini

  • Define required and optional Keyword Values and their data types
  • Validate MIME type, filename, size, content encoding, and business identifiers
  • Apply controlled vocabularies and formatting rules before import
  • Transform OnBase responses into the target application's canonical fields

Objective

Enforce authorization, duplicate prevention, routing, eligibility, and processing-state rules before writing or importing data.

Instructions in Martini

  • Check permissions separately from authentication success
  • Use stable source identifiers or business keys for duplicate detection
  • Route missing classifications, invalid Keywords, and unauthorized operations to controlled error handling
  • Do not log document content or sensitive Keyword Values

Common Hyland OnBase data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
DocumentsStored business documents together with searchable metadata and content.Salesforce, SAP, Microsoft Dynamics 365, ServiceNow, SharePoint, DocuSignMartini searches, imports, retrieves, maps, and synchronizes Documents while preserving the OnBase identifier, source key, content metadata, and processing status.
Document TypesClassification that determines how Documents are organized, secured, and processed.SAP, Workday, ServiceNow, Salesforce, Microsoft Dynamics 365Martini validates the required Document Type and applies routing and business rules before import or downstream synchronization.
Keyword Types and Keyword ValuesIndexed, typed metadata used to classify and retrieve Documents.CRM, ERP, HR, case-management, and records applicationsMartini maintains explicit field mappings, validates required and controlled values, handles formatting and multi-value behavior, and uses Keywords in search criteria.
FoldersLogical groupings for related Documents and business context.Salesforce, Microsoft Dynamics 365, ServiceNow, SharePointMartini maps approved folder relationships, checks permissions, and synchronizes folder references only when supported by the selected OnBase API.
Users and GroupsSecurity principals used for access control and workflow participation.Enterprise identity platforms, ServiceNow, WorkdayMartini can use confirmed identity or authorization operations to apply access-aware rules, but it does not assume that authentication grants access to every OnBase object.
WorkView objectsConfigurable business objects managed through the OnBase WorkView module.ServiceNow, Salesforce, Microsoft Dynamics 365Martini can integrate WorkView objects only when the relevant module and API operations are confirmed, with module-specific mappings and validation.

Authentication and security considerations

Authentication depends on the OnBase interface

OnBase deployments may use OAuth 2.0, a configured service identity, Windows-integrated authentication, or another enterprise mechanism. Confirm the API Server version, authorization server, grant type, scopes, token lifetime, certificates, and client registration with the OnBase administrator.

Authorization is separate from authentication

The service identity must have access to the relevant Document Types, Keyword Types, folders, Documents, content operations, and workflow or status functions. Test each required operation with least privilege.

Protect integration configuration

  • Store credentials, tokens, certificates, and endpoint settings as protected Martini configuration.
  • Use encryption in transit and avoid logging document content or sensitive Keyword Values.
  • Apply access controls appropriate for healthcare, personnel, financial, customer, and other regulated documents.

Operational considerations for Hyland OnBase integrations

Version and module dependency

OnBase capabilities vary by release, deployment topology, API Server configuration, and licensed modules. Confirm REST and SOAP coverage, Document Types, Keyword Types, Workflow or WorkView scope, and content operations before implementation.

Pagination and limits

Implement explicit pagination and server-side filters. Confirm search limits, concurrent request limits, token duration, request timeouts, reverse-proxy limits, import queue capacity, and maximum document size.

Content and idempotency

Large documents may require separate metadata and content handling, appropriate timeouts, and MIME-type and size validation. Persist source identifiers, OnBase document identifiers, content markers where appropriate, processing status, and error details to prevent duplicate imports.

Retries and reconciliation

Distinguish validation and authorization failures from transient timeouts or server errors. Use exponential backoff for transient failures, durable checkpoints for scheduled synchronization, and reconciliation workflows for partial or queued processing.

Schema and testing

Treat changes to Document Types, Keyword Types, permissions, API versions, and module configuration as integration-impacting changes. Test search, metadata reads, content reads, imports, status updates, permissions, large files, duplicates, and failure recovery in a representative environment.

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

Orchestrate more than one API call

Martini coordinates OnBase REST or SOAP calls with external applications, scheduled processing, validation, transformation, business rules, and downstream writes in a single maintainable workflow.

Separate provider details from business logic

Reusable mappings and services can isolate OnBase Document Types, Keyword Values, content handling, and authentication from a canonical integration model. This reduces duplication when multiple applications consume or submit documents.

Build controlled APIs

Martini can expose a controlled API façade over OnBase, centralizing authorization, search behavior, content handling, normalized responses, and error contracts instead of reproducing those concerns in every point-to-point client.

Operate reliably

  • Use checkpoints, idempotency, retry handling, pagination, and reconciliation for scheduled and batch processing.
  • Keep secrets and environment-specific endpoints out of workflow logic.
  • Monitor workflow outcomes while avoiding sensitive document content in logs.

Frequently asked questions

How can Hyland OnBase be integrated with enterprise systems?

OnBase can be integrated through its API Server REST capabilities for supported document, metadata, content, and search operations. Selected SOAP or web-service interfaces may be required for legacy deployments or operations not covered by REST. Document imports, content retrieval, scheduled polling, and approved callbacks can support synchronization, subject to the OnBase release, configuration, and licensed modules.

Can Martini integrate with Hyland OnBase?

Yes. Martini can consume the applicable OnBase REST API, use confirmed SOAP services where necessary, orchestrate document and metadata workflows, process content, and expose controlled Martini REST APIs for external callers. The exact interface and authentication model must be confirmed for the customer environment.

Do I need a connector to integrate Hyland OnBase with Martini?

No. A dedicated Hyland OnBase connector is not required. Martini can integrate using OnBase's confirmed REST APIs, selected SOAP or web-service interfaces, document-content operations, authentication methods, and scheduled workflows.

Is there any extra Lonti cost to integrate Hyland OnBase with Martini?

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

Which Hyland OnBase integration methods should a new project use?

Investigate the OnBase API Server REST interface first because it is the primary modern approach. Use document and file operations for content transfer, and consider SOAP or legacy web services only when the required operation is unavailable through the supported REST API or the existing deployment requires them. Confirm version, modules, and authentication before design.

Does Hyland OnBase provide webhooks or outbound callbacks?

A universal OnBase webhook model covering all document, Keyword, workflow, and content changes was not confirmed. Some modules or surrounding Hyland products may provide event, notification, or callback capabilities, but these must be verified for the specific deployment. Martini can use a scheduled polling workflow when no suitable callback is available.

How does synchronization with Hyland OnBase work?

Synchronization can use a confirmed event or callback, but scheduled polling is often the safer design when event coverage is uncertain. Martini queries supported OnBase endpoints with server-side filters and pagination, processes new or changed Documents, persists a checkpoint, and applies idempotency checks before downstream writes.

How are OnBase documents and metadata mapped?

Martini maps source fields explicitly to OnBase Document Types, Keyword Types, Keyword Values, folders, and content metadata. Mappings should define data types, required values, formatting, controlled vocabularies, and multi-value behavior. The OnBase document identifier and source business key should be retained for subsequent retrieval, updates, and reconciliation.

How should errors, retries, and duplicate imports be handled?

Separate authentication, authorization, validation, not-found, duplicate, content-transfer, timeout, and transient server failures. Use controlled retries with backoff for transient errors, durable checkpoints for scheduled processing, and stable source identifiers or business keys for idempotency. Do not rely only on filenames to detect duplicate Documents.

Can Martini expose an API façade over Hyland OnBase?

Yes. Martini can expose a controlled REST API that accepts a business identifier or document request, performs authorization and validation, searches or retrieves data from OnBase, and returns a normalized response. This centralizes OnBase-specific authentication, Keyword mapping, content handling, audit controls, and error behavior.