Aug 28, 2025
How Folio connects with suppliers
In this post, we'll explore how Folio connects with suppliers to deliver real-time purchasing workflows with zero implementation effort needed from either our supplier partners or hotel partners.
To quote a recent supplier partner:
I wish everybody had a modern platform like you guys. I have done nothing, and things are already happening. It's great.
We call our touchless approach to procurement Folio Lightning Automations.
To understand how Folio Lightning Automations work, let's begin with a brief dive into Internet history, starting with hypertext and the World Wide Web.
It's documents all the way down
Hypertext still feels magical to me.
Think about it: a bunch of documents on disparate computers, interconnected together through clickable underlined hyperlinks. Hierarchy and relationships forming and reforming with every new hyperlink. Extend this notion a bit further, and you’ve got the World Wide Web – a veritable superhighway of information, where anyone with a text editor and a dream can create a weird little home for their creativity or business – a place that anyone, anywhere in the world, can discover and visit.
It's really quite incredible to consider how the world economy's been completely transformed by this simple idea of documents linking to other documents.
Of course, hypertext requires a bit of syntax to make this all work, which is called HTML (Hypertext Markup Language). If you've ever been curious enough to right-click and "View Page Source" on a website, you've no doubt seen these <p> and <a> tags before. These are HTML tags and they describe the given webpage's content and structure.
Let's imagine a simple website that can be fully represented by a single HTML document.
When you visit this website on your web browser, the website's web server computer responds with a single file, like this:
Though it wins points for retro minimalism, our website's a little boring. Let's add an image of Folio's co-founder Al Hertz!
When your browser parses the HTML document and encounters this <img> tag, it will automatically make another request to the web server for the picture of Al Hertz:
Very neat!
Nowadays, your favorite websites are making dozens, if not hundreds, of additional file requests when you visit them. For fun, you might try following along with the "Network Tab" in your web browser to see these requests in action. These requests for documents and files are most commonly made via a protocol called HTTPS (aka Hypertext Transfer Protocol Secure).
To recap, when you tap a link on a webpage, your browser fires off an HTTP request, which is routed to a web server, which then returns an HTML file, which your browser can interpret, render to your screen, and use to request additional files as needed. For example, let's see what might happen when you're visiting the "Recent Orders" page on your favorite e-commerce website:
Your browser initially visits the "Orders" page, and then it will request a JSON document from the web server containing the details of your recent orders. Maybe you'll see a little spinner animation at this point. Once your browser receives this file with the orders data, the e-commerce web application can render your recent orders. Ideally, this all happens very quickly so you're never waiting too long.
In this sense, the Web is really just a bunch of files being shared securely between computers, using a specific document format, via a specific transfer mechanism.
We'll see this familiar pattern of document exchange again as we now return to procurement workflows.
Readin', writin', and procurem'nt
Up to this point, we’ve been talking about “read-only” experiences on the Web.
But the real magic of the web is interactivity, and this is where databases come into the picture. From social media to wikis to e-commerce, databases are key to delivering dynamic content on the web.
We're not going to dive too deeply into relational database theory in this post, but it's useful to recap the basic ways you can interact with "records" in a database.
Create: create a new record
Read: read one or more records
Update: update an existing record
Delete: delete a record
Conveniently, the HTTP protocol of the web follows the exact same pattern for its primary actions of interacting with resources (aka documents) on a web server.
Post: create a resource
Get: get a resource
Put/Patch: update a resource
Delete: delete a resource
Let's demonstrate how these concepts are aligned.
Imagine you run an e-commerce website selling donuts. A simplified version of your web infrastructure might resemble this:
Your web server handles incoming requests from web browsers and also communicates with your database, including handling user logins and authentications. The server acts a conduit between your customers and your database. Some of these interactions are READ / GET operations, like viewing product details and the pricing for a specific donut in your catalog. Some of those interactions are CREATE / POST operations, like placing an purchase order.
Let’s first walk through the READ / GET operation. Let's assume that Customer A and Customer B are both logged into your website using their secure credentials, and then they both visit the page for the "Sprinkle-1" donut to get updated pricing. Let's see what happens:
When Customer A visits the page for the Sprinkle 1 donut, their browser makes a GET request to the web server along with their unique login session cookies, which is followed by the web server issuing a READ request to the database, which queries for the Customer A's pricing for the Sprinkle-1 donut, returning an HTML (or JSON - JavaScript Object Notation) document with the pricing details, which happens to be $10.00. Then Customer A's browser will display the $10 price for the donuts.
However, when Customer B makes this same request for pricing for Sprinkle-1 donut, the server returns a price of $15.00, because this is their specific pricing as stored in the donut e-commerce database.
As demonstrated, the hypertext format and protocol of the Web was able to securely transfer unique pricing information via document exchange securely and directly between you and your individual customers.
Procurement protocols are document exchanges
This idea of facilitating procurement via transfer of well-defined documents predates even the Web.
EDI
The ANSI X12 EDI protocol - first developed in 1979, ten years before the Web, and still widely used today - does exactly this. Let me redo the visual above, replacing the web documents with representative EDI documents.
As you can see, it's essentially the same flow, with two major differences:
Instead of HTML or JSON documents, EDI exchanges tilde-delimited files that resemble spreadsheets
Instead of real-time exchanges via HTTPS protocol on web browsers, EDI files are dropped via SFTP into servers on some regular cadence (weekly or daily)
Both the Web protocols and the EDI protocols offer the ability to securely facilitate procurement workflows, but Web technologies offers significant advantages, specifically in enabling real-time pricing and stock-availability, which can be essential to many procurement scenarios. Additionally, from what we've observed, it often takes suppliers several weeks to configure new EDI connections for hotels — but with Folio Lightning Automations, there's no need for this setup cost and hotels can instantly start purchasing from suppliers.
PunchOuts and cXML
While the EDI protocol offers a set of standard documents, most suppliers have their own EDI format "flavor" based on their individual needs, and any procurement platform seeking to host a supplier catalog via EDI needs to write a "translation layer." There's often lengthy documentation shared between suppliers and procurement systems outlining these schema changes.
In the same manner, no supplier website represents their data in the exact same format. In an ideal world, supplier websites might communicate externally in a single global standard procurement schema (but I'm also reminded of this XKCD on standards as I say this).
As such, many suppliers recommend a PunchOut procurement workflow, which attempts to short-circuit any translation layer by having procurement take place directly on the supplier website using an authenticated login session.
But while PunchOuts (and cXML) do offer some advantages over EDI (like real-time pricing and stock availability), PunchOuts do introduce other procurement workflow UX challenges (including multi-staged approvals, lack of mobile UX, and others).
At the end of the day, both EDI connections and PunchOut systems require significant setup-costs for suppliers. Whether its developing translation layers for new EDI integrations or spinning up new PunchOut connections, many procurement teams are forced to contract with outsourced IT teams to connect with new hotels.
Folio Lightning Automations
Leveraging our team's years of experience building integrations with fintech banking infrastructure, Folio fully handles setting up real-time supplier integrations.
Our team has developed a schema for directly communicating with supplier websites, enabling a resource-efficient, secure document exchange based on the secure, encrypted credentials of each hotel property.
In many cases, Folio Lightning Automations are more resource efficient than loading PunchOut sessions because many of the operations of Lightning Automations (such as fetching order history) do not require loading the full supplier website — we can connect directly with these corresponding documents.
Lightning Automations facilitate hosted procurement in the same manner as EDI, but enable more of the advantages of the web, including the real-time information and photos found in PunchOuts but in a mobile-friendly platform, with approvals and budgets built-in.
You might think about procurement workflows about a spectrum from “hosted catalog” to “punchout." Each methodology uses a specific format and protocol, but they're still doing the same operations of securely connecting and transmitting documents.
Procurement tech | Format | Protocol |
|---|---|---|
EDI | ANSI X12 EDI* | SFTP |
Folio Lightning Automations | JSON | HTTPS / XMLHttpRequest |
PunchOut | CXML | HTTPS / XMLHttpRequest |
Folio Lightning Automations sit in the middle, bridging the real-time nature of PunchOuts with the advantages of a well-designed hosted catalog platform (mobile friendly, approvals, codings/budgets built in).
The final boss: building a purchase order
To solidify our understanding of Folio Lightning Automations, let's look at perhaps the most important of the procurement operations: submitting a purchase order. Each procurement technology, from EDI to PunchOut to Folio Lightning Automation, is going to assemble a document with the details of the purchase order to submit to the supplier platform. For simplicity's sake, let's zoom in on how they represent one of the line items of the order.
In spite of the syntactic difference, there are lots of commonalities here, which is not surprising at all. To order a specific product, we need to let the supplier know what we need — specifically, the product number, the quantity, and the price — so you'll see that information in all three documents.
Yes, the formats and syntax are slightly different, but it's still documents all the way down, and they all help facilitate important commerce in their own way.
Advantages of Lightning Automations
Through the same secure document exchanges that power e-commerce across the web, Folio Lightning Automations deliver a procurement workflow that brings together the very best User Experience from EDI hosted catalog experiences and supplier PunchOuts, with a zero-effort implementation time for suppliers or hotels.
We see key advantages for suppliers with Folio Lightning Automations. For one thing, there's no need to configure new EDI connections or PunchOut integrations - this means its easier to onboard new customers for suppliers. Also, from a security perspective, Folio Lightning Automations use the same credentials that each hotel property already uses to log into supplier websites. This means:
No new credentials to manage: Properties use their existing logins (or can work with Folio and suppliers to create a dedicated login using their same supplier account number)
Scoped access: Each hotel property only sees their own negotiated pricing and order history
Supplier-controlled: Suppliers maintain control through their existing authentication systems
Encrypted transmission: Credentials are encrypted in transit and at rest
From a hotel's perspective, Folio Lightning Automations offer significant advantages to existing technologies from a UX perspective, leading to more on-program procurement decisions.
EDI | Folio | PunchOut | |
Hosted Catalog |  | |  |
Mobile-friendly | Maybe | | |
Embedded Workflows | Maybe | | |
Real-time Prices | | | |
Real-time Stock | | | |
Instant Order Adjustments | | | |
Implementation time for supplier | 4 weeks | Zero work | 3-4 weeks |
Set-up time for hotel | 4-6 weeks | < 5 minutes | 1 week |
Stay in the loop
See if Folio could serve your operation. We’d love to reach out and share updates as they come.