Introducing the Aptos Integration Service Layer (ISL)

Look at any mature retailer's technology stack and you'll find the same story. A POS that talks to an OMS through a point-to-point integration built five years ago. An OMS that pushes orders to WMS via a bespoke flat-file drop. A tax engine wired in differently for stores than it is for eCommerce. A loyalty platform integrated through a webhook that nobody fully owns. A shipping carrier adapter that was a "temporary" fix in 2021.

Every one of these connections was reasonable in isolation. Together, they are what most architects privately call the integration tax: the silent cost line that shows up as longer go-lives, brittle upgrades, opaque incident triage and a steadily rising operational burden that scales with every new product, partner or store rollout.

We see this pattern across our customer base, and we see it inside our own portfolio. With products spanning POS (Aptos ONE and Aptos Store), OMS, WMS, Merchandising, CRM, Sales Audit and Enterprise Analytics plus an ecosystem of third-party tax engines, payment providers, carriers, marketplaces and customer-side systems, the surface area for integration sprawl is enormous.

That's the problem Aptos’ Integration Service Layer (ISL) is built to solve.

The patterns ISL standardizes

One of ISL's central goals is to compress every integration we do (and every integration our customers do against us) into a small set of well-understood patterns. Today, ISL natively supports:

• Synchronous and asynchronous API integrations for use cases where the caller needs an immediate response or can fire and forget
• Event-driven (Pub/Sub) integrations for the broad class of "something happened, anyone who cares should know" scenarios
• Batch and file-based integrations because real retail still moves a lot of data in nightly windows, and pretending otherwise doesn't help anyone

Across all three patterns, ISL applies unified Aptos Domain Canonicals: standardized data models that mean an order looks like an order regardless of which Aptos product emitted it, and a customer record carries the same shape whether it came from CRM, POS, or an external clienteling system. Domain Canonicals are how we eliminate the long tail of "almost the same field, named slightly differently" that makes integration debugging so painful.

What ISL actually is

ISL is a centralized, AWS-native integration backbone that brokers communication between Aptos products, third-party systems and customer endpoints through standardized patterns and reusable connectors. It is a governed platform with consistent routing, error handling, security and observability that any Aptos product or partner can integrate with once and reuse everywhere.

The mental model worth holding on to: Senders publish, ISL routes and delivers, consumers transform. Senders can be Aptos POS, Aptos OMS, a third-party system or any sender at all. Receivers are equally agnostic: Aptos products, third-party systems, customer-owned endpoints. ISL sits in the middle and enforces the contract.

Under the hood: AWS-native by design

For the architects and platform engineers reading this, the implementation matters as much as the abstraction. ISL is built on managed AWS services rather than self-hosted middleware, and that choice has real consequences for resilience, scaling and security posture.

The core components:

• Amazon EventBridge is the message bus at the heart of ISL: a serverless event bus that supports 1:1, 1:M and M:M routing patterns. One bus is provisioned per integration instance, and EventBridge handles secure delivery to any target, including another AWS account, a public API, a Lambda function or any AWS-native component.
• Amazon API Gateway provides the public HTTP entry point, handling authentication and request or event publishing into the platform.
• Amazon S3 serves as the storage layer, with one bucket per integration instance. Large payloads land in S3 and the message bus carries a reference rather than the full body. This is the Claim Check pattern, and it's what keeps the bus performant under enterprise volumes.
• Amazon SQS provides buffering and durability guarantees on the queueing side: one SQS per request type, one per event stream, independent of consumer availability.

The substrate is regionally deployed and operated by AWS, which means our teams are not managing message broker clusters, patching middleware servers or scaling event infrastructure manually. Capacity scales with traffic. Failover is regional and managed.

What this means for your team

For the technical audiences likely to be reading this (engineering leadership, integration architects, security teams, and developers building against Aptos), there are a few practical shifts worth understanding.

For developers and integration engineers, ISL means working with a consistent set of routing, Domain Canonicals and error-handling primitives instead of learning the quirks of each Aptos product's bespoke endpoints.

For architects, ISL is the answer to the question "How do we keep this maintainable as our footprint grows?" Decoupling integrations from the products they connect means a new release of Aptos OMS doesn't cascade into rewrites across every customer-specific connector. Integrations become first-class, versioned artifacts rather than embedded code paths.

For security teams, the design is governed by default. Authentication and authorization are enterprise-grade and centralized at the API gateway layer rather than re-implemented per integration. Communication is encrypted end to end. Observability is built in via Umbrella and CloudWatch, which means real-time visibility into what is flowing where and proactive alerting when something breaks. You don't have to negotiate with each product team for log access.

For CIOs and CTOs, the business case is straightforward: faster implementations because connectors are reusable, lower operational risk because every integration follows the same resilience patterns, and dramatically cleaner upgrade paths because the integration layer is decoupled from product release cycles.

Where ISL is being used today

ISL is live today, with adoption underway across several customer use cases. Adoption is being led by Aptos ONE and OMS to use ISL as their pattern for connecting to third-party shipping providers, tax providers, and email and address validation services with the Domain Canonical reused rather than rebuilt per integration. Other domains, including loyalty, customer and payments, are next on the adoption curve.

The bigger picture

A unified integration layer is not a customer-facing feature. It doesn't show up in a product demo the way a new clienteling experience or AI-driven pricing recommendation does. But for any retailer running a multi-vendor stack (which is, effectively, every enterprise retailer), the integration layer is one of the most consequential architectural decisions in the portfolio. It determines how fast you can move, how confidently you can upgrade and how much of your engineering capacity gets eaten by maintenance instead of innovation.

ISL is how Aptos is making that decision easier for our customers. One backbone. Standardized patterns. AWS-native scale. Governed by design. Built once, reused everywhere.

If you are an architect, developer or security lead on a retail technology team (and especially if you are working with us today on point-to-point integrations that you suspect could be doing more), we'd welcome the conversation about what moving to ISL looks like for your environment.

What's coming is even more exciting. On the roadmap is an AI-powered integration concierge built natively into ISL. Describe your source system, your target and your requirements and it proposes the right Domain Canonical, selects the appropriate integration pattern and generates a deployable configuration, all enforced by the same governance as any human-authored integration. The vision is to compress what today takes specialist expertise and multiple design cycles into a guided workflow that any capable engineer on your team can run. We look forward to sharing more details on this when we are closer to the launch.

If you would like to learn more about ISL and our investments in this area, please reach out to your Aptos representative, request a demo or connect with me on LinkedIn.