.png)
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.
Common Oracle MICROS Simphony integration patterns
Common Oracle MICROS Simphony data objects used in integrations
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.