Oracle PeopleSoft and Toast integration

What moves between them

The primary flow runs from Toast into PeopleSoft daily. Each business day, ml-connector polls Toast for completed orders and payments using the businessDate parameter aligned to each restaurant's closeout hour, retrieves all multi-location sites the credential can access, and aggregates sales and payment totals by revenue center or menu category. These are mapped to PeopleSoft GL accounts and cost centers and posted as daily reconciliation journals via SOAP component interface calls. Employee records flow from Toast into PeopleSoft on a weekly or bi-weekly schedule to keep headcount and labor assignments aligned, mapped to PeopleSoft job codes and departments. Configuration data such as payment methods and revenue centers are aligned in both directions. Orders and payments in Toast are read-only, so ml-connector never writes transactions back into Toast; writes are limited to employee records and order status updates where required for tracking.

How ml-connector handles it

ml-connector caches the Toast OAuth2 bearer token to avoid hitting authentication rate limits and tracks the PeopleSoft host, port, and node name per customer since each instance is unique. On each daily reconciliation run, it polls Toast for orders and payments using GET /ordersBulk with businessDate set to each restaurant's closeoutHour-adjusted date, retrieves all location GUIDs via GET /partners/v1/restaurants, and iterates through all locations. Voided orders and checks are filtered out before posting, and service charges classified as gratuity are handled according to the tenant's tax configuration. PeopleSoft write operations use SOAP component interface calls to post the aggregated journal, with date-range filtering and safe write semantics using natural object keys. Both APIs enforce rate limits and retry policies: Toast backs off at 20 req/sec with exponential backoff between locations, while PeopleSoft polling respects customer hardware constraints by filtering large result sets with date ranges rather than fetching all records at once. Every order, payment, and GL posting carries a full audit trail and can be replayed if a downstream GL write fails. API errors are normalized: Toast 429 (rate limit) triggers backoff; PeopleSoft 4xx errors are logged with the cryptic error body so the customer's PeopleSoft admin can investigate in their Integration Broker logs.

A real-world example

A multi-location casual dining group with 12 restaurants operates Toast for POS and labor across all sites, and uses PeopleSoft for consolidated GL and HCM. Before the integration, the accounting team exported daily order and payment summaries from Toast for each location, calculated totals by payment method and revenue center, and manually keyed reconciliation journals into PeopleSoft's GL each morning, a process that took 2 hours and was error-prone across multi-location sites and month-end close. They also struggled keeping PeopleSoft's employee roster aligned with Toast labor changes across 12 locations. With Toast and PeopleSoft connected, each night's close generates Toast sales and payment totals automatically, posts them to the correct GL accounts and cost center for each location, and employee changes sync weekly. The morning reconciliation is automated, month-end close finds GL labor accounts already balanced, and the manual re-keying is gone.

What you can do

• •Poll Toast daily by business date aligned to each restaurant's configured closeout hour, and post aggregated sales and payment reconciliation journals to PeopleSoft's general ledger.
• •Handle multi-location restaurant groups by iterating through all Toast location GUIDs and mapping each location to the correct PeopleSoft cost center.
• •Filter voided orders, checks, and payments before posting, and classify service charges correctly for tax and GL purposes.
• •Sync employee records from Toast to PeopleSoft on a weekly or bi-weekly schedule, mapped to job codes and departments.
• •Manage OAuth2 token caching for Toast and handle both HTTP Basic Auth and OAuth2 bearer token authentication for PeopleSoft depending on PeopleTools version.

Questions

How does ml-connector handle Toast's multi-location requirement and closeout hour complexity?

ml-connector retrieves all accessible restaurant locations via Toast's GET /partners/v1/restaurants endpoint and iterates through each location using its unique Toast-Restaurant-External-ID. For each location, it polls orders using the businessDate parameter adjusted for that location's configurable closeoutHour, so a sale at 1 AM June 12 correctly maps to June 11 if closeoutHour is 3 AM. Totals are aggregated by location and posted to PeopleSoft cost centers mapped to each site.

What happens when Toast or PeopleSoft APIs return errors or hit rate limits?

Toast rate limits (20 req/sec default, 1 req/sec for menu API) trigger HTTP 429 responses, and ml-connector backs off with exponential backoff between locations to avoid hammering the API. PeopleSoft errors are HTTP 4xx/5xx with cryptic error bodies; ml-connector logs the full error and audit trail so the customer's PeopleSoft admin can investigate in Integration Broker logs. Both systems support full replay if a write fails, with audit trail on every record.

Does ml-connector write sales orders back to Toast, or only read them?

ml-connector reads orders and payments from Toast as read-only data for reconciliation posting into PeopleSoft. It does not write sales transactions back into Toast. Write operations are limited to employee records and order status updates for tracking purposes where required; menu items and configuration data in Toast are read-only.