Welcome to GET PUT POST, a newsletter all about APIs. Each edition features an interview with an API-first business and killer app ideas for developers to build on their platform. Want the latest interviews in your inbox?
This edition, I spoke with Zack Kanter, Founder & CEO at Stedi. They’re modernizing an antiquated protocol that powers millions of transactions but you’ve probably never heard of it – EDI. We talk about this founder’s journey from the pain point of interacting with retailers to devising an modern API-first strategy. We also dive into their serverless architecture and how to gather feedback pre-launch. Enjoy!
How did you get started with Stedi?
I founded a brand of 2,200 auto parts manufactured in Taiwan and China. I was running the business myself and when it came time to sell my products to retailers, I didn’t want to manually enter orders one by one.
I reached out to all the retailers and said, “Can you send me your API spec? They all responded, “What’s an API? I explained, “I’m trying to automate all the orders. They told me, “You’re looking for EDI.”
EDI is a technology and taxonomy for thinking about how companies can talk to each other. It handles ~300 different transaction types, including everything from a purchase order and confirmation to instructions on how to load something onto an ocean carrier. It’s also a file format and a transfer protocol.
The taxonomy is elegant, but the file format and transfer protocol is hideous. If someone wants to sign up for EDI today, it’s an arcane process that involves scheduling a demo with sales on one of our competitors’ websites. They reach out, do a WebEx demo, receive a contract, negotiate the pricing, print it out, scan it, fax it back in, etc. Six months later, after a dozen screensharing sessions with an implementation specialist, they can start using EDI.
Our short-term vision is building a self-serve experience for EDI that feels like Shopify or Stripe. Any non-technical, business-minded user can sign up for EDI and automate their transactions or receive purchase orders from places like Wal-Mart, Amazon, or Best Buy within hours instead of weeks and months.
Why is there a custom protocol for commerce versus something like an XML feed?
EDI was developed in the 60s. It was originally mainframe-to-mainframe communication. This format was then picked up and popularized by Wal-Mart in the 80s. Wal-Mart was one of the leaders in popularizing EDI, automating transactions with their suppliers, and giving their suppliers data feeds that showed sales velocity so that they could do upstream planning.
This was before XML and JSON. Since data was extremely expensive back then (Wal-Mart was one of the the first companies to have their own satellite system for sharing this sort of data, which was expensive to do), it is optimized for what’s known in the EDI industry as kilocharacters (a kilocharacter is 1000 characters, which is roughly a kilobyte). They tried to optimize for keeping the kilocharacter count as low as possible. It’s this complex, hierarchical flat-file. It’s very odd, but it’s all designed this way in order to minimize data usage.
Then, when Amazon came about in the 90s and early 2000s, they wanted to do business with all the companies that were supplying Wal-Mart. The fastest way to onboard those supplier was to adopt the same standard the Wal-Mart was using. Fast forward to today, everybody uses EDI.
The specific type of EDI that is popular in the US is called the X12 standard. The amazing thing is that the entire retail commerce industry has basically adopted the same standard, which means that people can code to one standard instead of having to do 500 different one-off integrations for each retailer.
I’m divided on the merits EDI. If we all were to redo this from scratch today, under no circumstance would I say, “Let’s do it the same way with the same file format, optimize for kilocharacters, etc. However, if each retailer went out and designed their own awesome API and we had to integrate with thousands of different trading partners with their own APIs that changed over time, that would be a nightmare.
Even though it’s a standard, everybody has a different implementation or interpretation of it. If I’m looking at a given field in an EDI document, I know that it’s going to be one of 3,000 possible values with regard to units of measure. Each company might use five different units of measure, so there is some degree of configuration and customization involved in every EDI mapping.
And Stedi’s function is to abstract away those idiosyncratic differences?
That’s right. Our customers should never have to think about EDI. We handle all of the complexity and just give them our internal, canonical, JSON format.
Will you integrate with retailers individually or get open access to everyone?
We do have to integrate with each retailer individually, but because each is based on the same standard, we’re able to build a somewhat universal translation engine that is configured differently for each retailer. You can feed us purchase orders from Wal-Mart, Target, Amazon, and we map each one to our internal format.
There’s a fair amount of overlap from one to the other. Once we finish the first 50 retailers, we might be approaching 98% of the mappings that need to be done.
What has the feedback been from retailers?
EDI is a permissionless framework. As long as people can do the EDI handshake and create valid response documents in the EDI format, they generally don’t need to get permission from retailers. If someone wants to integrate via EDI with Amazon, for example, Amazon doesn’t have to approve the company that is handling the EDI integration.
For example, let’s say a water bottle brand sells $5mm worth of water bottles on Kickstarter. If Amazon wants to start stocking those water bottles in their warehouses, Amazon would set up a vendor relationship with the brand and start issuing purchase orders. If the manufacturer wanted to automate those orders, they would walk through Amazon’s EDI onboarding process. Amazon would ask, “What is your EDI server address? and that address could be Stedi’s EDI server, a competitor’s’ EDI server, or a server running in your garage.
There are ways that we can change that over time. Because so many of the EDI companies out there take so long to do integrations and their process is so difficult, we think that over time, if we do 50 awesome supplier integrations for a single retailer, the retailer might say, “Hey, this is working really well. This is taking one-tenth the time that our standard integration takes. Once that happens, we can work out some sort of deal with the retailers.
But in the short-term, it’s an invisible process – the retailer might not even know that Stedi exists.
Can you give some other examples of companies that would want to work with Stedi?
Anyone who’s selling a physical product to a major retailer could be a customer of ours.
Each EDI transaction has a number – e.g. 850 (purchase order) or 855 (purchase order confirmation) or 810 (invoice). There isn’t a purchase order for auto parts and another for electronics; it’s a single purchase order spec that encompasses any type of product that might be ordered. With the integrations we’ve built, we can automate transactions for any type of product from groceries to consumer electronics.
What’s your go-to market?
Six months ago, I would have said, “We’re going to start off by signing people who are not yet using EDI, because it’s going to be pretty hard to get people to switch. That was our first assumption.
But we’ve done some content marketing and I wrote a piece about Amazon for TechCrunch that went viral. We got a ton of beta signups. The crazy thing is that 9 out of 10 of our beta signups are current customers of our competitors.
We thought it would be the opposite, but Stedi resonates with people who have gone through or are going through the pain of an EDI implementation. It’s hard to imagine how bad it is until you’ve tried.
The trap that I’ve fallen into before is the “If you build it they will come assumption. Build a beautiful API and then assume people will just use it – but it doesn’t work that way.
I can’t go into our strategy in detail but there are a number of idiosyncrasies specific to EDI that we’ve figured out how to leverage.
Think forward 10 years when everyone who needs to integrate with retailers is doing it through Stedi.
There are two types of EDI: “webforms and “integrated.”
Webforms is really just a browser-based interface for manually processing EDI transactions. Believe it or not, the vast majority of EDI users today are using this manual webforms process where they are actually copying and pasting data for every single transaction.
Webforms is basically a portal that pulls together orders from different retailers allows the user to create response documents. For example, a company receives a purchase order, downloads that as a PDF or CSV, manually creates a purchase order confirmation, and then a ship notification and an invoice.
We think this whole process is crazy. The original dream of EDI was to automate all the transactions between two trading partners. Webforms isn’t automation – it’s just a marginally-faster way of manually processing transactions. We’re focusing on “integrated EDI, where we are fully automating the end-to-end transaction flow. We’re doing that with both our API and with prebuilt integrations to ERPs and other platforms like Flexport.
How the Flexport API enables global trade
Once we’re processing all of this structured data and everybody’s a Stedi customer, our plan is to build out a developer marketplace or app store that allows people to build business applications on top of our pipes.
Tell me more about your stack and what different technologies you’re using.
I’m a huge believer in the idea of serverless. We’re leveraging AWS Lambda and services like API Gateway, SQS, and RDS Aurora heavily. We’re months into building and we still have no servers, and we think that is going to give us a big advantage in terms of DevOps overhead down the line.
For us, using something like AWS Lambda, where we get a million requests for 20 cents, gives us a few advantages over our competitors. You can imagine what the weeks leading up to Black Friday and Cyber Monday is like for a legacy EDI company. Serverless gives us the ability to scale massively for peak demand without paying for any unused capacity.
It also means that we can do granular cost accounting on our transactions we want to land a huge retailer as a customer, we are going to have to get competitive on price. We tag all the Lambda and API gateway calls and know what it would cost down to fractions of a cent. We can figure out exactly what our transaction cost will be for processing an EDI document. That’s a lot harder to do with auto-scaling servers.
You’re using Java?
We are. We didn’t set out to use Java from the get-go. I said, “We’re going to try to be language agnostic and pick the best backend engineers we can find.” We interviewed a ton of people and the best person we found was a Java engineer.
The nice thing about using AWS Lambda is that if we wanted to, we could have one function in Python, one function in Java, and one function in something else. It’s easy to break everything apart.
Obviously, that would create other organizational issues; we’re trying to stick with Java for the most part, or at least JVM languages. At some point, we’ll probably rewrite our EDI parsing engine in something like Scala, but for now, we’re using Java. Java isn’t cool, but serverless is cool, and we think that balances it out.
How are you gathering customer feedback before you get started?
There’s a famous saying, “No restaurant ever went out of business for being too small. And that’s something we think about often.
The problem with EDI, however, is we can’t say, “Okay, we’re going to launch an MVP and people can receive purchase orders, but they can’t send confirmations or send invoices. All those things have to be done in order for it to be useful.
And we can’t hack it together and only have 99% of the messages go through successfully. We’re dealing with people’s money and with actual orders that are shipping real product in the physical world, so it has to be 100% accurate.
On top of that, few brands only sell to one retailer, so we have to build integrations for most of the major retailers in order to be useful for our customers.
So there is a big development hurdle, which is why we had to be a well-funded company in order to build a fully-functioning EDI platform even though we’re focusing on building a little as we possibly can in order to service early customers..
The problem we ran into was that we didn’t want to build in a vacuum. We needed a way to ship often and avoid working for months without any validation, but we couldn’t afford to screw up real customers’ transactions.
We have a unique advantage here. I still own the auto parts company I previously founded (though someone else runs it now), so we are able to roll out functionality piece-by-piece for a “real alpha customer without fear of really pissing anyone off. This closed feedback loop allowed us to build really quickly – we were able to quickly start processing live transactions without any potential reputational risk.
For finding bugs and figuring out all the edge cases that come up with EDI, we have a cohort of pilot users who are automating their retailer relationship using Stedi before we start onboarding paid users. Ultimately, we’re working with beta users who have real businesses and can give us brutal feedback, because that gives us the information we need to make the platform great. Once we have everything dialed in for the first cohort of early users, we’ll be ready to publicly launch.
If you like the post, I’d really appreciate you sharing it on Twitter.
Want more API interviews in your inbox?
Latest comments (1)
Nice job on the explanation of EDI and its uses in the industry! There is precious little references in GitHub and within the open source community. Interesting choice with Java. How do you deal with HIPAA/ACA requirements on AWS?