Ellipse Gradient for Header

Oracle MICROS Simphony Integration Guide

Integrate Simphony restaurant POS data with enterprise applications through Oracle Hospitality REST APIs, OAuth 2.0, selected notifications, scheduled synchronization, and supported exports.

Oracle MICROS Simphony integration options at a glance

Oracle MICROS Simphony integrations are primarily built with Oracle Hospitality REST APIs and transaction-oriented services, authenticated with OAuth 2.0 bearer tokens and, where required, application keys, scopes, and roles. Selected deployments may also expose legacy SOAP services, notification mechanisms, reporting or data-transfer capabilities, and scheduled file exports. Broad webhook coverage and a universal bulk API are not confirmed, so polling and incremental extraction may be necessary. Martini can orchestrate authenticated API calls, paginate and checkpoint transactions, transform Simphony objects, process supported files, apply reconciliation rules, and expose intermediary APIs for downstream applications.

Integration pointSupported by Oracle MICROS Simphony?Common use casesHow Martini supports it
REST APIsYesOracle Hospitality provides REST-based cloud APIs for supported Simphony-related services, including transaction-oriented operations and selected operational data.Martini can consume Simphony REST APIs from workflows, manage authentication and pagination, transform payloads, and expose REST APIs for downstream consumers.
AuthenticationYesOracle Hospitality cloud APIs commonly use OAuth 2.0 bearer tokens with application registration, client credentials, application keys, scopes, and roles as required.Martini stores client secrets, application keys, tokens, URLs, and other environment values in protected configuration or secrets and uses them in API workflows.
SOAP APIsLegacyLegacy or deployment-specific Oracle MICROS web services may expose SOAP operations where an equivalent REST operation is unavailable.Martini can consume SOAP services when the customer's enabled Simphony deployment requires them, while keeping REST as the preferred new-integration boundary.
Webhooks / outbound callbacksLimitedSelected Oracle Hospitality notification or event services may be available, but broad webhook coverage for checks, menus, employees, payments, and configuration changes was not confirmed.Martini can expose an authenticated API to receive confirmed callbacks; otherwise it can use scheduled polling and incremental synchronization.
Bulk / async / batch APIsLimitedReporting, data-transfer, export, and batch capabilities may support large transaction or reporting synchronizations, depending on the service and license.Martini can partition work by location or business date, checkpoint progress, process pages or batches, and route failed partitions for retry.
File / attachment APIsLimitedOracle-supported reporting or data-transfer services may provide scheduled file exports, but a general Simphony attachment API was not confirmed.Martini can receive or process supported files, validate schemas and naming rules, transform rows, and track duplicate files and reprocessing state.
Database / analytics accessLimitedDirect SQL access to Oracle-managed Simphony production databases should not be assumed; reporting, export, or data-transfer services are the safer boundary.Martini can connect to a separate customer-managed staging or reporting database, but this does not imply access to Oracle-managed production databases.

How Oracle MICROS Simphony exposes data and business events

Simphony REST APIs

Oracle Hospitality provides REST-based cloud APIs for supported Simphony-related services. Available resources and operations depend on the Simphony release, subscribed service, deployment model, and tenant configuration.

Martini implementation pattern

Martini implementation pattern: a workflow obtains or refreshes the required OAuth 2.0 token, calls the documented Simphony service, handles pagination and service responses, maps the result to a canonical model, and writes it to the target system.

Implementation sequence

Obtain an OAuth 2.0 access token and required application context
Call the documented Simphony REST resource
Retrieve all pages or incremental partitions
Map the response to the canonical integration model
Apply validation and business-date rules
Write the result and persist the checkpoint

Transaction Services

Simphony Transaction Services APIs support transaction-oriented operations involving POS activity and restaurant operational data. They should not be treated as a complete replacement for every administrative or configuration interface.

Martini implementation pattern

Martini implementation pattern: the workflow selects locations and business dates, retrieves or submits the supported transaction payloads, normalizes checks, lines, tenders, taxes, and adjustments, and uses durable identifiers for reconciliation and retry handling.

Implementation sequence

Select the supported transaction service and scope
Request the required location or business-date partition
Process transaction pages and nested check data
Normalize tenders, taxes, discounts, and service charges
Apply duplicate and reconciliation rules
Post validated results or record controlled exceptions

Notifications and callbacks

Selected Oracle Hospitality services may provide notifications or event-oriented functions, but broad webhook coverage for every Simphony business event was not confirmed.

Martini implementation pattern

Martini implementation pattern: where a required notification is available, Martini exposes an authenticated receiving API, validates the callback, retrieves the current Simphony resource when necessary, and treats the notification as a trigger rather than a complete source of state.

Implementation sequence

Receive the confirmed notification or callback
Authenticate and validate the incoming request
Extract the resource or event reference
Retrieve current Simphony state when required
Apply idempotency and business rules
Acknowledge the callback and record processing status

Scheduled extraction and exports

When event delivery is unavailable, Simphony integrations can use scheduled polling, incremental queries, reporting services, data-transfer services, or supported file exports depending on the deployment.

Martini implementation pattern

Martini implementation pattern: a scheduled workflow partitions work by location and business date or documented update field, consumes APIs or supported files, persists progress, and routes failed partitions to a retryable exception path.

Implementation sequence

Start the workflow on a controlled schedule
Load the last durable checkpoint
Retrieve the next location, date, page, or file partition
Validate the response or file schema
Transform and deliver the partition
Persist progress and route failures for retry

Legacy SOAP services

Some Oracle MICROS deployments may expose SOAP-based or legacy web services. Availability depends on the Simphony version and deployment model, and REST should generally be evaluated first for new cloud integrations.

Martini implementation pattern

Martini implementation pattern: Martini consumes the confirmed SOAP contract, stores endpoint and authentication configuration securely, maps XML requests and responses, and isolates legacy service logic behind a reusable workflow or API.

Implementation sequence

Confirm that the required legacy operation is enabled
Load the SOAP endpoint and protected credentials
Build and send the XML request
Parse and validate the XML response
Map the result to the canonical model
Handle service faults and retry only transient failures

Common Oracle MICROS Simphony integration patterns

Pattern 1: Synchronize Simphony transactions to finance

When to use this pattern

Use this pattern to post completed sales, checks, tenders, taxes, discounts, and settlement information to an accounting or finance platform. It is suitable when broad event delivery is unavailable and transaction extraction must be controlled by business date and location.

Integration direction
Oracle MICROS Simphony
Martini
Oracle Fusion Cloud Financials
Example Mapping
Oracle MICROS Simphony FieldCanonical FieldTarget Field
locationIdlocation.externalIdBusinessUnit
businessDatesales.businessDateAccountingDate
transactionTotalsales.grossAmountJournalLine.Amount
tenderTypepayment.methodPaymentMethod
Martini implementation pattern

A scheduled workflow retrieves paginated transactions by location and business date, normalizes nested checks and financial adjustments, validates totals and required dimensions, and writes idempotent finance batches. It persists checkpoints, retries transient API or target failures with backoff, and sends validation or reconciliation exceptions to a controlled queue or case process.

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

Pattern 2: Synchronize menus and prices

When to use this pattern

Use this pattern when Simphony menu items and price levels must be aligned with an approved product, pricing, or commerce source. Write operations must be validated against the customer's enabled Simphony API and location permissions.

Integration direction
Shopify
Martini
Oracle MICROS Simphony
Example Mapping
Oracle MICROS Simphony FieldCanonical FieldTarget Field
product.idmenuItem.externalIdMenuItemId
product.titlemenuItem.nameMenuItemName
price.amountmenuItem.pricePriceLevel.Amount
availableAtmenuItem.effectiveDateEffectiveDate
Martini implementation pattern

Martini consumes the source catalog, validates revenue-center applicability, tax behavior, effective dates, and location overrides, then transforms approved items into the applicable Simphony request model. The workflow compares stable identifiers, avoids unsafe name-based updates, records rejected changes, and retries only transient write failures.

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

Pattern 3: Synchronize restaurant master data

When to use this pattern

Use this pattern to align organizations, properties, locations, revenue centers, or employees with an enterprise master-data or workforce platform. It is useful for maintaining consistent routing and operational ownership across a hospitality group.

Integration direction
Workday
Martini
Oracle MICROS Simphony
Example Mapping
Oracle MICROS Simphony FieldCanonical FieldTarget Field
organization.externalIdorganization.externalIdOrganizationReference
location.externalIdlocation.externalIdPropertyId
revenueCenter.coderevenueCenter.codeOutletCode
worker.idemployee.externalIdEmployeeReference
Martini implementation pattern

A scheduled or approved event-driven workflow retrieves source changes, maps hierarchy and employee relationships using stable identifiers, applies location and permission rules, and sends only supported updates to Simphony. Martini records correlation IDs, rejects ambiguous mappings, and exposes exception results for operational review.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • validation
  • conditional routing
  • monitoring

Pattern 4: Reconcile POS activity with finance data

When to use this pattern

Use this pattern when finance or operations teams need to compare Simphony transaction totals with payment, settlement, or accounting data by location and business date.

Integration direction
Oracle MICROS Simphony
Martini
Oracle NetSuite
Example Mapping
Oracle MICROS Simphony FieldCanonical FieldTarget Field
businessDatereconciliation.businessDatePostingDate
revenueCenterIdreconciliation.revenueCenterDepartment
tenderTotalreconciliation.tenderAmountSettlementAmount
taxTotalreconciliation.taxAmountTaxTotal
Martini implementation pattern

Martini extracts Simphony transactions and target settlement data, groups them by location, business date, revenue center, and tender type, and applies tolerance and exception rules. Results are written to a database or target finance system, while duplicate keys, late corrections, voids, refunds, and failed partitions are retained for reprocessing.

Martini capabilities used
  • workflows
  • API consumption
  • database connectivity
  • data mapping
  • business rules
  • error handling

Applications commonly integrated with Oracle MICROS Simphony

Oracle MICROS Simphony can be integrated with finance, hospitality, workforce, customer, and operational platforms. Exact flows depend on the customer's Simphony release, enabled Oracle Hospitality services, permissions, and the target application's API capabilities.

Application Scenario Direction Martini Pattern
Oracle NetSuite Post restaurant sales, payments, tax, and settlement data into accounting and ERP processes. Oracle MICROS Simphony → Martini → Oracle NetSuite A scheduled workflow retrieves completed transactions by location and business date, maps checks, tenders, taxes, discounts, and settlement references, then writes idempotent accounting records and routes exceptions for review.
Oracle Fusion Cloud Financials Transfer summarized sales, tender, tax, and reconciliation information into enterprise finance processes. Oracle MICROS Simphony → Martini → Oracle Fusion Cloud Financials Martini extracts and validates Simphony transaction totals, groups them according to finance rules, transforms the result into the target API model, and retries transient posting failures without duplicating successful batches.
Oracle OPERA Cloud Coordinate hotel, property, outlet, and restaurant operations where the customer's Oracle Hospitality services support the required flows. Oracle OPERA Cloud → Martini → Oracle MICROS Simphony Martini orchestrates the applicable Oracle Hospitality APIs, correlates property and outlet identifiers, applies tenant-specific business rules, and records rejected or unsupported operations for controlled reprocessing.
Salesforce Synchronize restaurant, property, account, service, or operational information for hospitality and franchise processes. Oracle MICROS Simphony → Martini → Salesforce A scheduled or event-assisted workflow retrieves approved Simphony data, maps stable organization, location, and employee identifiers to Salesforce objects, validates required fields, and sends failed records to an exception path.
Workday Align employee or organizational information with workforce and operational processes. Workday → Martini → Oracle MICROS Simphony Martini consumes authorized Workday changes, maps employees and organizational structures to Simphony's permitted model, applies least-privilege and location rules, and logs records that require manual approval.
ServiceNow Create incidents or operational cases when POS, location, or integration failures require IT service management. Oracle MICROS Simphony → Martini → ServiceNow Martini monitors workflow failures and Simphony exception conditions, enriches incidents with location and business-date context, and creates or updates ServiceNow incidents while using correlation keys to prevent duplicates.
Shopify Reconcile or coordinate online and physical food-service sales where a restaurant business operates both commerce channels. Shopify → Martini → Oracle MICROS Simphony Martini compares channel transactions, normalizes product, location, tax, and tender data, applies approved synchronization rules, and sends only validated changes through the applicable Simphony service.

How to build a Oracle MICROS Simphony integration in Martini

Objective

Establish the Simphony API boundary and protect all tenant-specific credentials and identifiers.

Instructions in Martini

  • Confirm the Simphony release, deployment model, enabled service, base URL, organization, enterprise, and location identifiers.
  • Configure OAuth 2.0 client credentials, application keys, scopes, roles, and protected Martini secrets.
  • Use the least privilege required for the selected Simphony objects and operations.

Objective

Select an event-driven, scheduled, or API-led trigger based on the confirmed Simphony capability.

Instructions in Martini

  • Use a confirmed callback only for the selected event and deployment.
  • Use a scheduler for polling, incremental extraction, reporting, or file-based synchronization.
  • Partition scheduled work by location, business date, update time, or documented service boundary.

Objective

Call the appropriate Simphony service and obtain complete, current source data.

Instructions in Martini

  • Consume the documented REST or confirmed legacy SOAP operation.
  • Implement the service-specific pagination model and retrieve all required pages or partitions.
  • Persist a durable checkpoint outside the individual workflow execution.

Objective

Coordinate source calls, enrichment, target writes, and exception paths in a maintainable Martini workflow.

Instructions in Martini

  • Separate extraction, transformation, validation, delivery, and reconciliation stages.
  • Correlate location, revenue center, business date, and source identifiers across the flow.
  • Use reusable services or APIs for shared authentication and normalization logic.

Objective

Convert Simphony payloads into the canonical and target application models.

Instructions in Martini

  • Map organizations, locations, revenue centers, menu items, checks, transactions, and employees by stable identifiers.
  • Normalize nested check lines, taxes, discounts, service charges, tenders, and financial totals.
  • Preserve business dates, time zones, source references, and raw payloads when auditability is required.

Objective

Protect operational and financial integrity before committing changes.

Instructions in Martini

  • Validate required fields, supported enumerations, effective dates, location permissions, and reconciliation tolerances.
  • Handle voids, refunds, reopened checks, late-posted transactions, corrections, and duplicate source identifiers.
  • Reject ambiguous mappings and route them to an exception process rather than guessing.

Common Oracle MICROS Simphony data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
Organizations and locationsRepresent enterprise, property, restaurant, and operational location structures used to route data and establish ownership.Oracle Fusion Cloud Financials, Oracle OPERA Cloud, Salesforce, WorkdayMartini preserves stable Oracle identifiers, maps hierarchy relationships, and avoids using display names as primary keys.
Revenue centersRepresent dining rooms, bars, concessions, and other operational service points.Oracle NetSuite, Oracle Fusion Cloud Financials, data warehousesMartini maps revenue-center identifiers to target dimensions and applies location-specific routing and validation.
Menu itemsRepresent products sold through the POS, including definitions, prices, and menu configuration.Shopify, Oracle OPERA Cloud, product or pricing servicesMartini maps item identifiers, price levels, effective dates, tax behavior, and revenue-center applicability before writing approved changes.
Checks and check linesCapture guest checks, ordered items, service charges, discounts, taxes, and payment-related information.Oracle NetSuite, Oracle Fusion Cloud Financials, SnowflakeMartini retrieves pages of checks, normalizes nested lines and adjustments, preserves business dates, and applies idempotent destination writes.
TransactionsRepresent completed POS activity, sales information, tenders, and other financial transaction data.Oracle Fusion Cloud Financials, Oracle NetSuite, customer data warehousesMartini extracts transactions incrementally, correlates location and business-date context, handles corrections and late arrivals, and stores checkpoints.
Employees and usersSupport POS staffing, operational identity, and authorization-related integrations.Workday, Salesforce, ServiceNowMartini applies least-privilege mappings, validates organization and location relationships, and separates identity attributes from authorization decisions.

Authentication and security considerations

OAuth 2.0 and application configuration

Oracle Hospitality cloud APIs commonly use OAuth 2.0 bearer tokens. Simphony integrations may also require an Oracle application key, API-specific scopes, roles, organization identifiers, and tenant-specific URLs.

Least-privilege access

Grant only the Simphony organization, location, object, and operation permissions required by the workflow. Validate authorization requirements separately for each subscribed service.

Protected secrets

  • Store client secrets, application keys, tokens, and environment URLs in protected Martini configuration or secrets.
  • Do not embed credentials in workflows or log access tokens.
  • Restrict and authenticate any Martini API used to receive callbacks or expose Simphony data.

Payment and sensitive data

Confirm whether card-related information is tokenized or excluded from each API response. Limit payload retention and logging to the data required for the integration and its audit obligations.

Operational considerations for Oracle MICROS Simphony integrations

Rate limits and retries

Oracle quotas and throttling may vary by service and tenant. Use bounded concurrency, exponential backoff, and controlled retries for transient 429, 5xx, and network failures.

Pagination and checkpoints

Follow the pagination model specified by each Simphony API. Persist checkpoints outside a workflow execution and use business date, transaction time, update time, or another documented incremental field where available.

Business dates and corrections

Preserve property time zone, POS business date, transaction timestamp, settlement date, and revenue-center context. Account for late-posted transactions, voids, refunds, reopened checks, settlement adjustments, and other corrections.

Idempotency and schema changes

  • Use stable Simphony identifiers with location, business date, and transaction version where necessary.
  • Store processed identifiers or source hashes in a durable staging or reconciliation store.
  • Monitor new enum values, optional fields, menu changes, tender changes, and organizational updates.
  • Test against the customer's exact release, services, permissions, and representative data.

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

Orchestration across systems

Martini coordinates Simphony API calls, target-system writes, enrichment, validation, reconciliation, and exception handling in maintainable workflows rather than scattering logic across scripts.

Reusable integration assets

Teams can expose controlled APIs and reuse authentication, mapping, transformation, and business-rule services across locations, properties, and downstream applications.

Operational reliability

Martini supports scheduled and event-assisted processing, durable checkpoints, bounded retries, structured error paths, and monitoring for workflows that handle high-value transaction and reconciliation data.

Flexible boundaries

When Simphony webhooks or direct database access are unavailable, Martini can combine REST APIs, legacy SOAP where required, supported files, polling, and customer-managed staging databases without implying unsupported native access.

Frequently asked questions

How can Oracle MICROS Simphony be integrated with enterprise systems?

Simphony is primarily integrated through Oracle Hospitality REST APIs and transaction-oriented services using OAuth 2.0. Depending on the deployment, organizations may also use selected notifications, scheduled polling, reporting or data-transfer services, supported file exports, and legacy SOAP services.

Can Martini integrate with Oracle MICROS Simphony?

Yes. Martini can consume Simphony and Oracle Hospitality REST APIs, authenticate with OAuth 2.0 and required application credentials, orchestrate transaction and master-data workflows, transform payloads, and expose intermediary APIs. Confirmed SOAP, callback, or export mechanisms can also be used where the customer's deployment supports them.

Do I need a connector to integrate Oracle MICROS Simphony with Martini?

No dedicated Oracle MICROS Simphony connector is required. Martini can use Simphony's confirmed native REST APIs, OAuth 2.0 authentication, selected callbacks, scheduled polling, supported exports, or deployment-specific SOAP services.

Is there any extra Lonti cost to integrate Oracle MICROS Simphony with Martini?

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

Which Simphony integration methods should be used for a new implementation?

REST APIs and the Oracle Hospitality Integration Platform should generally be evaluated first for new cloud integrations. Transaction Services may support transaction-oriented flows, while scheduled extraction, reporting, data-transfer, or file services can support larger synchronizations. SOAP is generally a legacy or deployment-specific option.

Does Simphony support webhooks or event notifications?

Broad webhook coverage for every Simphony object was not confirmed. Selected Oracle Hospitality notification or event services may be available, but the required event and deployment must be verified. Martini can receive a confirmed callback; otherwise, scheduled polling or incremental extraction is appropriate.

How does Martini synchronize Simphony checks and transactions?

Where the enabled Simphony API exposes the required data, Martini can retrieve checks or transactions by location and business date, paginate through results, preserve source identifiers, map nested financial details, and write them to a target application or database. Durable checkpoints and idempotent writes help manage corrections and duplicates.

Can Martini expose an API façade for Simphony data?

Yes. Martini can expose a controlled REST API that hides Simphony-specific authentication, resource details, transformations, and business rules from downstream applications. The façade can validate requests, orchestrate Simphony calls, restrict access, and return a canonical response model.