PromoStandards is one of the most impressive things the promotional products industry has built. A consortium of suppliers and distributors came together, agreed on a common data language, and published eight API standards that cover the core transactions of the industry. Product data. Pricing. Inventory. Order status. Invoice. The basics.
That is genuinely hard to do. Getting competitors to agree on anything is hard. Getting them to agree on technical specifications is harder. PromoStandards deserves credit for existing.
But after two years of working inside the iPromoteu integration layer, I came to understand something uncomfortable: the standard was also the bottleneck.
The Problem With Consensus Standards
Consensus standards are designed to be acceptable to everyone. That means they are optimized for the lowest common denominator: the capabilities that every participant in the consortium can support. The result is a standard that is technically implementable by every supplier but strategically limiting for the distributors who need to build on top of it.
The PromoStandards product data standard defines how a supplier communicates product attributes. It covers the basics: product name, description, SKU, color, size. What it does not cover well is the relational complexity of promotional products: the fact that a single product can have dozens of decoration methods, each with its own pricing matrix, each with its own lead time, each with its own setup charge, and that the combination of product plus decoration method plus quantity creates a pricing surface that is genuinely complex.
The standard was not designed to encode that complexity. It was designed to encode the minimum information needed to display a product in a catalog. For catalog display, it works fine. For building a data lake that can answer complex sourcing questions, it is insufficient.
The Integration Ceiling
This is what I mean when I say the standard was the bottleneck. We had ninety vendors integrated via PromoStandards. Getting to a thousand vendors via the same approach was not just a capacity problem: it was an architectural problem.
The PromoStandards integration model assumes that each integration is a bilateral relationship: one supplier, one distributor, one set of API calls. That model does not scale. It does not scale technically, because you are managing hundreds of individual connections. And it does not scale informationally, because each connection encodes the relationship between that supplier and that distributor in isolation.
What we needed was a multilateral model: a central schema that encoded the relationships between all suppliers and all products and all decoration methods, and a pipeline that could ingest data from any supplier who conformed to the standard and map it into that central schema.
The standard was a starting point, not a destination. But because the industry had invested so heavily in point-to-point integrations built on the standard, there was significant inertia against rethinking the architecture.
What I Would Do Differently
If I were starting the data lake project over, I would start with the schema, not the standard. I would define the relational model that the business needs: the entities, the relationships, the attributes: and then figure out how to map the PromoStandards data into that model.
The standard tells you what data suppliers can provide. The schema tells you what data the business needs. Those are different questions, and the gap between them is where the real product work lives.
I would also invest earlier in the domain expertise extraction. The people who understood the relational complexity of the industry: the decorators, the account managers, the sourcing specialists: had knowledge that no API spec could capture. Getting that knowledge into the schema before the engineers started building would have saved months of rework.
The Broader Lesson
Every industry has its version of PromoStandards. Healthcare has HL7. Financial services has FIX. Automotive has STAR. These standards are valuable. They create a common vocabulary. They reduce the cost of bilateral integration. They are worth supporting.
But they are not a product strategy. They are a starting point. The product work is figuring out what the standard does not cover: and building the architecture that fills that gap.
