Ellipse Gradient for Header

Applied Epic Integration Guide

Applied Epic integrates with enterprise systems primarily through Applied Systems-authorized REST APIs using OAuth-based access and controlled synchronization workflows.

Applied Epic integration options at a glance

Applied Epic is principally integrated through Applied Systems-authorized REST APIs. Depending on the tenant, subscription, API program, and permissions, Martini can retrieve and update Accounts, Contacts, Policies, Claims, Activities, and Opportunities. OAuth-based authorization requires an approved application and securely managed credentials. General-purpose webhooks, callbacks, bulk APIs, attachment APIs, GraphQL, SOAP, and direct database access are not publicly confirmed and should be validated with Applied Systems. Where event delivery is unavailable, Martini can schedule incremental REST API polling with pagination, checkpoints, overlap windows, mapping, validation, and controlled retries.

Integration pointSupported by Applied Epic?Common use casesHow Martini supports it
REST APIsYesRead Accounts, Contacts, Policies, Claims, Activities, and Opportunities; retrieve related objects; and create or update selected records where the tenant permits it.Martini can consume the Applied Epic REST API, paginate responses, transform payloads, apply business rules, and expose selected results through a Martini API.
AuthenticationLimitedApplied Systems API access generally requires an approved application and OAuth-based authorization, with tenant, agency, scope, and permission details confirmed during onboarding.Martini can store client credentials and tokens in secure configuration and use the Applied Systems-approved authorization pattern without placing secrets in mappings or logs.
Scheduled synchronizationYesScheduled incremental retrieval is a practical alternative when Applied Epic event delivery is unavailable or limited. Modified-date filters, cursors, or equivalent vendor-supported criteria should be confirmed.Martini scheduler-triggered workflows can persist high-water marks, process pages, use overlap windows, and coordinate non-overlapping runs.
Webhooks / outbound callbacksNot confirmedApplied Systems may provide partner-specific events, callbacks, or notifications, but general-purpose coverage across Applied Epic objects is not publicly confirmed.Martini can receive webhook-style callbacks when Applied Systems documents and enables them for the relevant tenant and event; otherwise it can use scheduled polling.
Bulk / asynchronous APIsNot confirmedNo general-purpose Applied Epic bulk or asynchronous API was publicly confirmed. Large synchronizations should use documented pagination and incremental filters unless Applied Systems provides another interface.Martini can process bounded pages and batches, persist progress, control concurrency, and resume failed work without assuming a bulk endpoint.
File / attachment APIsNot confirmedApplied Epic manages agency documents and insurance-related files, but a general-purpose public attachment API was not verified.Martini can orchestrate file exchange if Applied Systems confirms the required endpoints and permissions; document handling should not be designed on assumption alone.
SDKsNot confirmedApplied Systems has historically provided SDK and partner resources, but the supported SDKs, languages, object coverage, and Applied Epic availability require confirmation.Martini integrations should use the confirmed REST boundary and only invoke an SDK when it is available and supported in the target deployment environment.
Database accessNoDirect access to Applied Epic managed production data should not be assumed. The supported boundary is the Applied Systems API or another explicitly approved interface.Martini can write synchronized data to an approved downstream database, but it should not connect directly to Applied Epic production storage.

How Applied Epic exposes data and business events

Applied Epic REST APIs

Applied Systems provides an Applied Epic API and developer program centered on REST-style access. Detailed endpoints, object coverage, permissions, and write operations may require customer, partner, or developer authorization.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with the Applied Systems-approved OAuth method, calls the required REST resources, follows documented pagination, validates and maps the response, and writes it to downstream systems or returns it through a controlled Martini API.

Implementation sequence

Obtain the approved Applied Systems API application and authorization details
Authenticate using the vendor-approved OAuth flow
Request the required Applied Epic resource
Follow the documented pagination or continuation method
Map and validate the response against the target model
Apply ownership, duplicate, and privacy rules before writing data

Applied Epic event notifications

General-purpose Applied Epic webhooks for all business objects and changes are not publicly confirmed. Partner-specific callbacks or notifications may be available for selected tenants and use cases.

Martini implementation pattern

Martini implementation pattern: when Applied Systems documents an applicable callback, Martini receives the notification, authenticates and validates it, retrieves the current resource when necessary, and runs the same mapping and idempotency logic used by scheduled synchronization. If no event mechanism is available, the workflow uses polling.

Implementation sequence

Confirm event coverage and callback security with Applied Systems
Receive the notification through a Martini API or webhook workflow
Validate the event and identify the affected Applied Epic object
Retrieve the current resource when the notification is only a change signal
Apply mapping, business rules, and duplicate protection
Record the event outcome and route failures for retry or review

Applied Epic scheduled synchronization

Scheduled incremental polling is the practical fallback when event delivery is unavailable or limited. The API's supported modified-date filter, change token, cursor, or equivalent criterion must be confirmed.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that loads the previous checkpoint, retrieves changed pages, processes related objects in dependency order, writes results, and advances the checkpoint only after successful processing. A small overlap window helps reduce boundary misses.

Implementation sequence

Start the workflow on a controlled schedule
Load the last successful checkpoint and overlap window
Request changed Applied Epic objects using the documented criterion
Process each page with bounded concurrency
Persist successful object and pagination progress
Advance the checkpoint only after the run completes successfully

Common Applied Epic integration patterns

Pattern 1: Synchronize Applied Epic customers to a CRM

When to use this pattern

Use this pattern when agency teams need Applied Epic Accounts, Contacts, Opportunities, and selected Activities in Salesforce, Microsoft Dynamics 365, or HubSpot. Applied Epic remains authoritative for insurance-specific fields while CRM ownership is limited to agreed marketing or sales attributes.

Integration direction
Applied Epic
Martini
Salesforce
Example Mapping
Applied Epic FieldCanonical FieldTarget Field
Account identifiercustomer.externalIdAccount.AppliedEpicId
Contact name and emailcustomer.contactContact.Name and Email
Opportunity statussales.opportunityStatusOpportunity.StageName
Activity due dateworkItem.dueAtTask.ActivityDate
Martini implementation pattern

A scheduled Martini workflow retrieves changed objects, resolves Account and Contact relationships, normalizes values, and applies field-level ownership rules before upserting CRM data. Stable external identifiers prevent duplicates, while transient failures are retried and permanent validation failures are quarantined with object identifiers.

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

Pattern 2: Load Policies and Claims into reporting

When to use this pattern

Use this pattern when an agency needs a governed reporting or analytics dataset without direct database access to Applied Epic. The workflow retrieves changed Policies and Claims, preserves relationships, and writes normalized data to an approved database or Snowflake loading process.

Integration direction
Applied Epic
Martini
Snowflake
Example Mapping
Applied Epic FieldCanonical FieldTarget Field
Policy identifierpolicy.externalIdpolicy.applied_epic_id
Policy effective datepolicy.effectiveDatepolicy.effective_date
Claim identifierclaim.externalIdclaim.applied_epic_id
Claim statusclaim.statusclaim.status
Martini implementation pattern

A scheduler starts the workflow, which loads a high-water mark, retrieves paginated changes, validates Policy and Claim relationships, and writes bounded batches. Martini records checkpoints only after successful writes, applies rate-aware retries, and restricts logs because insurance data may be confidential.

Martini capabilities used
  • scheduler triggers
  • API consumption
  • pagination orchestration
  • mapping and transformation
  • checkpoint management
  • database or API writes
  • monitoring and error handling

Pattern 3: Route Applied Epic Activities to ServiceNow

When to use this pattern

Use this pattern when agency Activities need centralized operational routing, escalation, or service visibility. A reverse update can be considered only when the Applied Epic API exposes the required write operation and the ownership model is explicit.

Integration direction
Applied Epic
Martini
ServiceNow
Example Mapping
Applied Epic FieldCanonical FieldTarget Field
Activity identifierworkItem.externalIdServiceNow.correlation_id
Activity subjectworkItem.summaryIncident.short_description
Activity due dateworkItem.dueAtTask.due_date
Activity statusworkItem.statusIncident.state
Martini implementation pattern

Martini polls Activities or receives a confirmed notification, filters eligible work items, enriches them with permitted Account or Contact context, and creates or updates ServiceNow records. Routing rules determine assignment and priority; duplicate checks and retry-safe writes prevent repeated tasks.

Martini capabilities used
  • scheduled or event-driven workflows
  • REST API consumption
  • data enrichment
  • conditional routing
  • field mapping
  • business rules
  • retry and duplicate handling

Pattern 4: Initiate document signing from Applied Epic data

When to use this pattern

Use this pattern when an agency wants to start a DocuSign workflow from approved Applied Epic Account, Contact, or Policy information. It should be implemented only after Applied Systems document and attachment behavior is confirmed for the required use case.

Integration direction
Applied Epic
Martini
DocuSign
Applied Epic
Example Mapping
Applied Epic FieldCanonical FieldTarget Field
Account nameparty.nameenvelope.recipient.name
Contact emailparty.emailenvelope.recipient.email
Policy numberpolicy.referenceenvelope.customField.policyNumber
Signing completionworkflow.statusApplied Epic activity or approved status field
Martini implementation pattern

A Martini workflow retrieves the approved Applied Epic data, validates recipient and policy fields, creates the DocuSign request, and tracks completion. Completion updates are mapped back only through documented Applied Epic write operations; attachment exchange and failure recovery are isolated so a signing retry does not create duplicate envelopes.

Martini capabilities used
  • workflow orchestration
  • REST API consumption
  • data transformation
  • validation
  • business rules
  • status tracking
  • error handling

Applications commonly integrated with Applied Epic

Applied Epic data can be exchanged with adjacent enterprise applications when the agency has a defined system-of-record model and the required APIs and permissions are available. These are architectural integration patterns rather than claims of native Applied Systems partnerships.

Application Scenario Direction Martini Pattern
Salesforce Synchronize selected Accounts, Contacts, Opportunities, and Activities with CRM and sales processes while retaining Applied Epic as the operational insurance system for appropriate data. Applied Epic → Martini → Salesforce Martini consumes Applied Epic REST API data on a schedule or through a confirmed callback, matches records using stable identifiers, maps fields to Salesforce objects, applies ownership rules, and retries transient failures without creating duplicates.
Microsoft Dynamics 365 Align agency customer, contact, opportunity, and activity information with Microsoft CRM processes. Applied Epic → Martini → Microsoft Dynamics 365 A Martini workflow retrieves changed Applied Epic objects, validates required fields, transforms them into Dynamics 365 requests, and optionally routes approved updates back to Applied Epic where write permissions exist.
HubSpot Provide marketing and sales teams with selected customer or prospect information while retaining Applied Epic as the operational insurance platform. Applied Epic → Martini → HubSpot Martini filters permitted Accounts, Contacts, and Opportunities, removes or masks unsuitable insurance data, maps the approved subset to HubSpot, and records source identifiers for safe replay.
ServiceNow Route operational Activities, incidents, or service requests involving agency operations into centralized work-management processes. Applied Epic → Martini → ServiceNow Martini polls or receives confirmed Applied Epic notifications, maps Activities and relevant context to ServiceNow records, applies routing rules, and optionally sends status updates back when the Applied Epic API allows the operation.
DocuSign Use approved Account, Contact, or Policy information to initiate document-signing workflows and return completion status to an agency process. Applied Epic → Martini → DocuSign → Martini Martini retrieves the required Applied Epic data, transforms it into a DocuSign request, tracks the signing response, and updates an agency workflow. Document and attachment endpoints must be confirmed before implementing file exchange.
Microsoft Teams Deliver selected activity, claim, or operational notifications to agency teams. Applied Epic → Martini → Microsoft Teams A Martini workflow identifies qualifying Applied Epic Activities or Claims, applies notification and data-minimization rules, and sends a formatted message to a Teams-supported endpoint or API.
Snowflake Consolidate Policy, Claim, Account, and Activity data for reporting and analytics. Applied Epic → Martini → Snowflake Martini incrementally retrieves and normalizes Applied Epic data, persists checkpoints, validates relationships, and writes bounded batches to an approved staging or data-loading interface for Snowflake.
NetSuite Exchange customer, billing, or operational information where an agency uses NetSuite for finance or back-office processing. Applied Epic → Martini → NetSuite Martini maps selected Applied Epic Accounts and approved operational fields to NetSuite records, applies field ownership and duplicate checks, and sends only explicitly authorized updates in the reverse direction.

How to build a Applied Epic integration in Martini

Objective

Establish the Applied Epic integration boundary using an Applied Systems-approved API application, tenant details, OAuth authorization data, and environment-specific configuration.

Instructions in Martini

  • Confirm the Applied Epic API product, version, tenant, agency, and permitted objects
  • Register or obtain the Applied Systems-approved application credentials
  • Store credentials and tokens in Martini secrets or secure environment configuration
  • Separate development, test, and production settings where available

Objective

Select event-driven processing only when Applied Systems confirms the required callback or notification; otherwise use scheduled incremental polling.

Instructions in Martini

  • Confirm whether the required object and event have callback coverage
  • Use a Martini API or webhook workflow for an approved notification
  • Use a scheduler when event delivery is unavailable or limited
  • Define a non-overlapping schedule and an overlap window for timestamp boundaries

Objective

Consume the Applied Epic REST API and retrieve complete, authorized object sets using documented pagination and incremental criteria.

Instructions in Martini

  • Request Accounts, Contacts, Policies, Claims, Activities, or Opportunities as required
  • Apply vendor-supported modified-date filters, cursors, or change criteria
  • Follow pagination until the response is complete
  • Persist page progress and high-water marks where appropriate

Objective

Coordinate dependencies, enrichment, validation, and downstream calls in a maintainable Martini workflow.

Instructions in Martini

  • Process related objects in an appropriate order such as Account, Contact, Policy or Claim, then Activity
  • Separate transient failures from authorization and validation failures
  • Control concurrency and avoid overlapping synchronization runs
  • Use reusable workflow logic for common API and checkpoint behavior

Objective

Convert Applied Epic data into the target application's model while preserving identifiers, relationships, and data ownership decisions.

Instructions in Martini

  • Map vendor fields to a canonical or target model
  • Normalize dates, statuses, identifiers, and relationship references
  • Validate required fields and permitted values
  • Minimize sensitive insurance data sent to downstream systems

Objective

Enforce system-of-record, duplicate-prevention, routing, and write-permission rules before changing data in another platform.

Instructions in Martini

  • Use stable Applied Epic identifiers as external keys
  • Define authoritative fields for Applied Epic and each target system
  • Perform controlled lookups before creates when no documented upsert exists
  • Prevent update loops and avoid overwriting agency-managed information

Common Applied Epic data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
AccountsCustomer or agency account information associated with insurance operations.Salesforce, Microsoft Dynamics 365, Snowflake, NetSuiteMartini retrieves changed Accounts, matches them using stable identifiers, validates ownership and required fields, and maps them to downstream models or approved write operations.
ContactsPeople and organizations associated with Accounts, Policies, Activities, or other agency records.Salesforce, HubSpot, Microsoft Dynamics 365, SnowflakeMartini resolves account relationships, applies duplicate-prevention rules, minimizes sensitive data exposure, and transforms contact fields for the target system.
PoliciesInsurance policy records, relationships, and lifecycle information.Snowflake, Salesforce, reporting databases, approved document workflowsMartini treats Policies as potentially authoritative Applied Epic data, retrieves them incrementally, validates relationships, and routes them according to field-level ownership rules.
ClaimsClaim records associated with insured Accounts and Policies.Snowflake, Microsoft Teams, reporting databases, ServiceNowMartini applies restricted-data handling, maps Claim context to approved destinations, records processing status, and avoids exposing unnecessary payload details in logs.
ActivitiesTasks, notes, communications, follow-ups, and other agency work items.ServiceNow, Salesforce, Microsoft Teams, Microsoft Dynamics 365Martini filters Activities by type or status, maps them to work-management objects, applies routing rules, and optionally sends permitted completion updates back to Applied Epic.
OpportunitiesProspective business or sales opportunities managed by the agency.Salesforce, HubSpot, Microsoft Dynamics 365Martini synchronizes approved opportunity fields, preserves external identifiers, applies source-of-truth rules, and prevents update loops in bidirectional flows.

Authentication and security considerations

OAuth-based authorization

Applied Epic API access generally requires an Applied Systems-approved application and OAuth-based authorization. The exact grant, scopes, token lifetime, and tenant-selection process must be confirmed through Applied Systems onboarding.

Tenant and permission controls

Access may depend on the agency, tenant, subscription, partner status, object permissions, and user or application authorization. Do not assume that normal agency administrator credentials can be used directly for API access.

Secret protection

  • Store client credentials, refresh tokens, and access tokens in Martini secrets or secure environment configuration.
  • Do not place credentials in mappings, source code, request payloads, or routine logs.
  • Use separate credentials and configuration for development, testing, and production where available.
  • Apply least privilege to Accounts, Contacts, Policies, Claims, Activities, and Opportunities.

Sensitive insurance data

Policies, Claims, Contacts, and related information may be confidential or regulated. Restrict payload logging, define retention policies, and limit downstream data to what each business process requires.

Operational considerations for Applied Epic integrations

Pagination and incremental retrieval

Do not assume one response contains all Accounts, Policies, Claims, or Activities. Follow the Applied Epic API's documented pagination method and use modified-date filters, cursors, or equivalent incremental criteria where available.

Rate limits and concurrency

Universal Applied Epic request limits were not publicly confirmed. Limit concurrency, use controlled page sizes, honor rate-limit responses, apply exponential backoff, and prevent overlapping scheduled runs.

Checkpoints and idempotency

Persist the last successful synchronization time, pagination cursor, object identifiers, and retry state. Use a small overlap window for timestamp boundaries and stable Applied Epic identifiers to prevent duplicate writes.

Relationships and ownership

Process related data in an appropriate order, such as Account, Contact, Policy or Claim, then Activity. Define which system owns each field before implementing bidirectional synchronization.

Schema and testing

Object fields, permissions, relationships, and enumerations may vary by API version or tenant. Version mappings, validate required fields, test representative data, and monitor for schema or permission changes.

Error handling

Retry transient failures and rate-limit responses, but route authentication and validation failures for operational attention. Capture rejected object identifiers and messages without exposing sensitive payloads.

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

Orchestrate more than an API call

Point-to-point scripts often combine authentication, pagination, transformation, business rules, retries, and logging in one fragile implementation. Martini separates these concerns into maintainable workflows and reusable integration assets.

Support changing integration requirements

Martini can consume the Applied Epic REST API, map its objects to different target models, apply field ownership rules, and expose a controlled REST API for downstream consumers. The same workflow approach can support scheduled polling or a confirmed vendor callback.

Improve operational reliability

  • Persist checkpoints and process bounded pages instead of relying on one large request.
  • Apply controlled retries and distinguish transient failures from permanent data errors.
  • Centralize secrets and environment configuration.
  • Monitor workflow execution and troubleshoot failed objects without rerunning an entire synchronization.

Keep vendor boundaries explicit

Martini does not require direct database access to Applied Epic or an assumed native connector. It works through the vendor-approved API boundary while providing the orchestration, transformation, validation, and API exposure needed around that boundary.

Frequently asked questions

How can Applied Epic be integrated with enterprise systems?

Applied Epic is principally integrated through Applied Systems-authorized REST APIs. Enterprise workflows can retrieve and, where permitted, update Accounts, Contacts, Policies, Claims, Activities, and Opportunities. Scheduled incremental synchronization is a practical approach when event delivery is unavailable or limited; any callbacks or notifications must be confirmed for the tenant and use case.

Can Martini integrate with Applied Epic?

Yes. Martini can integrate with Applied Epic by consuming its authorized REST APIs, using the approved OAuth-based authentication method, orchestrating scheduled or confirmed event-driven workflows, mapping data, and routing it to other applications. No native Martini Applied Epic connector was verified in the supplied research.

Do I need a connector to integrate Applied Epic with Martini?

No. A dedicated Applied Epic connector is not required. Martini can use Applied Epic's confirmed native integration mechanisms, principally its REST APIs and approved authentication process, plus any vendor-documented callback, event, or file mechanism that is available for the customer.

Is there any extra Lonti cost to integrate Applied Epic with Martini?

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

Which Applied Epic integration methods should architects use?

Use the Applied Systems-authorized REST API as the primary method. Use OAuth-based authorization and confirm object-level permissions, tenant configuration, pagination, filters, and write operations. GraphQL, SOAP, general-purpose bulk APIs, direct database access, and general attachment APIs should not be assumed.

Does Applied Epic provide webhooks or events for changes?

General-purpose webhooks for every Applied Epic object and state change are not publicly confirmed. Applied Systems may provide partner-specific callbacks or notifications, so coverage must be verified for the tenant and API program. Martini can receive a confirmed callback or use scheduled incremental polling as a fallback.

How does Martini synchronize Applied Epic data?

Martini can retrieve changed objects using vendor-supported modified-date filters, cursors, change tokens, or equivalent criteria, then paginate through results and persist a high-water mark. Overlap windows, stable external identifiers, dependency ordering, and field-level ownership rules help prevent missed changes, duplicates, and update loops.

How does Martini handle Applied Epic errors, retries, and duplicates?

Martini workflows can distinguish transient timeouts, server errors, and rate limits from authentication or validation failures. Transient failures can be retried with controlled backoff, while malformed requests are routed for correction. Stable Applied Epic identifiers, controlled lookups, checkpoints, and idempotent target writes make retries safer.

Related Martini documentation

APIs

Workflows

Data

Security

Operations

Build a maintainable Applied Epic integration with Martini

Use Martini to connect Applied Epic through its approved APIs, orchestrate reliable synchronization workflows, and map insurance agency data to the systems your organization already uses.

EXPLORE MARTINI
BOOK A DEMO