Puente OS
Back to resources
Puente OS vs· 23 min read· Cris Ugarte, CEO of Puente OS

Puente OS vs Custom Middleware: Integrating Your Systems and Keeping Them Connected

Custom middleware is the integration your development team, a freelancer or a software development agency builds to connect your ERP with your eCommerce, your marketplaces, your WMS or your invoicing system. It gives you full control of the code and fits your system exactly. Puente OS builds that connection inside the full process that uses it: the database that cross-references your systems, the workflows with your rules, the App where your team resolves exceptions and the agents for the steps that take judgment, all on a single platform. After it goes live, every integration needs someone to adapt it each time an API, a credential or a format changes. In Puente OS, the Growth Ops team that built it with you does that work, and each process reaches production in 2 to 4 weeks.

Puente OS vs Custom Middleware: Integrating Your Systems and Keeping Them Connected

Custom middleware is software built for your company that sits between two or more systems and translates, moves and syncs data between them: marketplace orders into your ERP, ERP stock into your store, the order into your WMS or the sale into your invoicing system. Puente OS is the platform that builds the systems that run your business: apps, workflows, databases and agents that read from your systems, cross-reference the information none of them holds in full, decide on your rules and execute the action inside them. Middleware carries data from one system to another, and Puente OS connects your systems and runs the work that data sets in motion.

I'm Cris Ugarte, CEO and co-founder of Puente OS. We work with retail, eCommerce and logistics companies in Chile, Peru and Mexico, and many of them already run custom-built integrations: a script that pulls marketplace orders, a connector between the store and the ERP or a nightly job that pushes stock. The question that comes up is concrete: should the next integration be custom-built, or built with Puente?

My answer starts by looking at an integration's whole life. Building it is the first stage, and then comes keeping it alive while APIs, credentials, rules and people change. Here I go through what each path solves, with public sources for everything I say about the industry and the platforms, and when each one fits.

What is custom middleware and what does it solve?

Custom middleware solves a specific connection precisely: the code does what your system needs, with your fields, your exceptions and your way of working, and it stays under your control. Your own development team, a freelancer or a software development agency builds it, and it usually takes one of these forms:

  • A connector between your eCommerce or marketplaces and your ERP, which brings orders into the ERP and sends stock and prices back to each channel.
  • A sync with your WMS or your logistics operator, which sends orders to be picked and brings back shipping statuses.
  • A connection with your invoicing system, which issues the tax document for each sale.
  • A scheduled job that reads files, such as a spreadsheet or an FTP drop, and loads them into another system.

Its strengths are real:

  • Full control. Your company decides the code, the logic and where it runs.
  • Exact fit. It adapts to a heavily customized ERP, an in-house system or a format no tool handles out of the box.
  • Open scope. Any system with an API, a database or a readable file can be connected.

Building one takes weeks. A digital agency that builds eCommerce-ERP integrations estimates, in October 2026, for the Amsterdam market, 6 to 12 weeks per connector depending on the ERP: 2 weeks of data mapping, 3 to 6 of development and 2 to 4 of testing in a staging environment. An eCommerce connector provider describes four phases for integrating Shopify with an ERP (data flow mapping, build, testing and training, launch and stabilization) and says most of these projects take 8 to 16 weeks.

In the same estimate, the agency sets the point where a custom connector is enough: 2 to 4 data flows. Above 5 flows, or with several ERPs, it recommends an integration platform (iPaaS).

A precise connection, built to fit your system and under your control: that is the job of custom middleware.

What is Puente OS and what does it solve?

Puente OS is the platform that builds the systems that run your business. In your stack it is the system of action: it reads from your systems, cross-references the information none of them holds in full, decides on your rules and executes the action inside them, writing back.

What it builds comes from four pieces:

  • Databases that bring together context from several systems: the marketplace order, its document, its shipment and its payment in a single record.
  • Workflows that connect your systems and apply explicit, auditable rules. They start on their own at a set time or when another system notifies them by webhook that something changed.
  • Agents for the steps that take judgment, like an ambiguous complaint or a discrepancy that needs investigating.
  • Apps where your team reviews, decides on and approves the exceptions.

Connections are built with whatever each system offers. Puente has native connectors for WooCommerce, Multivende, Mercado Libre and Bsale, among others: with Multivende it updates stock in bulk, with Mercado Libre it reads orders and each shipment's detail, and with Bsale, stock and documents. For everything else, and to write back to those same systems, a workflow calls the API over HTTP or with Python, receives events by webhook or reads the ERP's database when that is the available access. In production, for example, Puente connects to SAP Business One with a Python workflow that reads its database every day.

With Puente OS you describe in natural language what your operation needs and get software running: apps, workflows, databases and agents. Puente's Growth Ops team builds each process with you and maintains it, and each one reaches production in 2 to 4 weeks. Puente acts on your systems, and where the operation lives in spreadsheets, it also keeps the record.

The discipline behind it is autonomous operations design: designing your operation so the repeatable work runs on its own, on your rules, and your team decides what takes judgment. One of its conditions is the one every integration pursues: your systems talk to each other on their own. For a closer look at the layer, see what a system of action is.

What happens to an integration after it goes live?

The longest stage of its life begins. The APIs it depends on change, credentials expire, platforms raise their requirements and the operation asks for new rules. An integration in production needs someone who adapts it continuously and understands how it works. An integration agency puts it plainly: sooner or later a sync fails, because of an item deleted in the ERP, a customer without an account, a network outage or a version update, which is why it recommends testing every update in an environment connected to a copy of the ERP.

Platforms update their APIs on their own schedule:

  • Shopify releases a new API version every three months, on the first day of each quarter, and supports each stable version for at least 12 months. When a version is retired, calls fall forward to the oldest supported version. Its REST Admin API became a legacy API on October 1, 2024, and since April 1, 2025 every new public app is built exclusively with the GraphQL Admin API.
  • VTEX announced on May 23, 2025 that its legacy Webservice API would be discontinued on September 1 of that year, and the stores using it had to migrate to its REST APIs. In 2023 it had already deprecated a checkout endpoint that integrations had to replace with its OMS endpoints.
  • Bsale, a Chilean point-of-sale and invoicing system, publishes an API changelog: in 2025 it logged changes in 11 of the 12 months, and in October of that year it lowered its limit from 10 to 8 requests per second. Several of its entries are new validations, such as one on negative values in the netUnitValue field, from January 2026.
  • Falabella requires every request to its Seller Center API to carry a User-Agent header in a defined format (seller, technology, version, integration type and country), and its multiwarehouse stock flow requires version 2.0 of GetOrders and GetOrder.
  • Defontana, a Chilean ERP, recommends in its API documentation having a development team that implements and maintains the integration, because that development is "the responsibility of the client or its technology provider." Each new token instantly invalidates all previous ones for the same user, and its test environment is overwritten every week with production data and is down on weekends.
  • SAP Business One recommends on SAP Learning restarting the Service Layer services at least once a day and scheduling bulk operations during low-concurrency hours. Sana Commerce, an eCommerce provider for SAP, reports that the DI Server, another SAP Business One integration path, is in passive support, and its migration guide to the Service Layer warns that, when migrating, some features of its own platform stop working because field names differ between the two, and they have to be reconfigured.

Credentials and access rules need constant attention:

  • On Mercado Libre, the access token expires after 6 hours and the refresh token is single-use: each renewal issues a new one and only the latest is valid. The token is also invalidated early if the user changes their password, the app updates its Client Secret, the user revokes permissions or the app goes 4 months without calling the API.
  • Mercado Libre publishes its Integration Security plan, updated March 4, 2026, as the standard it requires of integrators: secret rotation, mandatory MFA, authentication on every endpoint, rate limiting, encryption of personal data, webhook validation with HMAC-SHA256, anomaly monitoring and a process ready to revoke tokens in bulk, among other requirements.
  • Mercado Libre can also block an application for failing its data validation or its terms, for excessive calls or token misuse, or for data violations, and an excess of unexpected 4xx errors can trigger the block. A blocked app loses access to every Mercado Libre and Mercado Pago API, and its sellers have to operate by hand from the site.

What comes after launch is most of the work. Integration infrastructure providers describe it in detail. Ampersand, which builds integration infrastructure for SaaS companies, estimates that in the integrations those companies ship to their customers, the visible build is about 30% of the lifetime work, and that most teams underestimate it by a factor of two or three. What follows: API version migrations, schema changes, token refresh, rate limits, webhook retries and behavior nobody documented. OpusGo, another provider, adds that point-to-point code breaks with ERP patches.

And continuity depends on how much of what is known gets written down outside the head of whoever built it. Research measures it with the bus factor, or truck factor: the minimum number of developers who would have to leave for a project to stall. Across 133 popular GitHub projects, a study presented at ICPC 2016 found that 65% have a truck factor of 2 or less. These are open source projects, and in industry the diagnosis repeats: in a survey of 269 engineers, carried out with JetBrains, the bus factor shows up as a significant problem in team development.

Documentation is the other half. In GitHub's 2017 Open Source Survey, 93% of respondents had encountered incomplete or outdated documentation.

Those changes reach every integration, including the ones Puente builds. What defines how much they weigh on your operation is who adapts the connection, how quickly they learn that something changed and how much of what they know is written down. When an integration stops, your team goes back to moving data by hand, and that work has a name: the coordination tax.

How do Puente OS and custom middleware compare, dimension by dimension?

Custom middleware delivers the connection that was specified, and Puente OS delivers the process that uses it, with the connection inside and a team that maintains it. Dimension by dimension:

  • Timeline. Custom middleware: 6 to 12 weeks per connector according to an agency estimating the Amsterdam market, across mapping, development and testing, and 8 to 16 according to a connector provider. Puente OS: 2 to 4 weeks per process, connection included.
  • Scope. Custom middleware: the connection specified in the project, with its translation rules: which field maps to which, how often it runs and what it does with an error. Puente OS: the connection and the process that uses it, with the database that cross-references the sources, the workflows with your rules, the App where your team sees each exception and the agents for the steps that take judgment.
  • API changes. Custom middleware: each new version, expiring credential, rate limit or new validation is adapted in the code, by whoever holds maintenance. Puente OS: the Growth Ops team adapts the connection when an API, a channel, a rule or a format changes, and the Mercado Libre and Multivende connectors include their own token refresh step. A workflow's new version inherits the same webhook and the same schedule, so your systems keep calling the same place.
  • Monitoring and failures. Custom middleware: the logs, alerts and retries the project includes. Puente OS: every run stores its status, the step where it stopped and, for each step, the error and its log, and failure alerts include an excerpt of the error. Each step defines whether a failure stops the process or lets it continue, and processes that write to another system use patterns such as a connection check at the start, an idempotency key to avoid duplicates and a lookup of the real state before retrying a send.
  • History and rollback. Custom middleware: the version control and deployment process defined by the team that maintains it. Puente OS: every workflow save creates a version, with author and date, and rolling back means activating the previous one. Every app publish is also kept as a version in its history. Before an irreversible action, the workflow can leave a draft for your team to confirm.
  • Who maintains it. Custom middleware: your development team, the freelancer or the agency that built it, depending on what you agree. Puente OS: the Growth Ops team that built it with you, which maintains it as your operation grows.
  • Documentation. Custom middleware: whatever your team writes and keeps up to date alongside the code. Puente OS: the rules are written explicitly in each workflow, and the version and run history shows what changed, when, and what ran at each step.
  • Permissions and audit. Custom middleware: whatever is designed in the project, on the infrastructure where it runs. Puente OS: each app gets explicit per-table permissions (read, write or delete), with least privilege, and the tables and connections belong to your team on the platform. Columns with sensitive data can be encrypted: only a workflow from your own team reads the real value, and each read leaves an audit event with its metadata, with the value kept out of the logs.
  • Growing into another process. Custom middleware: each new connector goes through its own mapping, development and testing. Puente OS: the next process is added on the same connections and the same data, and arrives faster than the first (see Example 3).
  • How it's built. Custom middleware: written in code, by whoever develops it. Puente OS: you describe in natural language what your operation needs and get software running; in the operation, a model reads what arrives messy and an agent takes the steps that need judgment, while the critical logic runs on explicit, auditable rules.

What does it look like in a real operation?

It looks like integrations that live inside complete processes, with one person who builds them on the platform and a team that maintains them. Three Puente OS customers:

Example 1: seven channels and 19 APIs at a multichannel electronics seller in Mexico

An electronics seller in Mexico runs without an ERP, and Puente has seven of its sales channels connected, with 19 APIs in total. Every order Puente ships follows its path on rules: the address is validated, the carrier is chosen by rules on zone, shipping type and insurance, the label is generated and the tracking number is written to the order. Puente also consolidates 213,362 Mercado Libre orders via API into a single sales report.

Between November 2025 and August 2026, Puente processed 38,628 orders end to end, and 97.9% went out with their label with no human intervention: 37,815 labels. Generating the labels for a cutoff went from 5 to 7 hours to 15 minutes, and monthly volume grew 40% with the same operations team. Between August 1 and 12, 12 of 2,051 orders had an incident, 0.59%, with a median resolution time of 10 minutes. Behind it are 20 apps and 75 processes, built in ten months by one person from Puente on the platform: the rules, the versions and every run stay visible to the team.

Example 2: two channels in one CRM and a catalog over FTP at a Chilean retailer

A Chilean retailer sells in its physical store and its online store. Puente consolidated orders from both channels into a single CRM: 27,656 orders between December 2025 and August 2026, with 9,686 identified customers. Its catalog arrives over FTP and refreshes three times a day, in a run of about five minutes.

From the demo to the CRM operating with daily ingestion took 6 weeks. Today there are 13 apps, 25 tables and 108 deployed versions, built and maintained by one person from Puente on the platform: each version is a change that reached production.

Example 3: data flowing back to the store at a pet retailer in Chile

A pet retailer sells on four channels. A workflow calculates the margin of every sales line each day: as of August 2026 it had covered 247,626 lines, and 3,830 of them, 1.5%, showed a negative margin that nobody saw before. Prices are executed from Puente and written back to its online store: 8,362 changes as of that date. Each shipment is measured against the delivery promise using the courier's API: of 32,708 shipments evaluated, 85.0% met it.

There are 10 apps in production and 167 versions deployed in ten months, built and maintained by one person from Puente on the platform, with everything visible to the team. The time between requesting a new process and having it in production dropped from 105 days, on the first project, to 7.

Why choose Puente OS?

Because Puente OS builds and runs the complete system around each connection: apps, workflows, databases and agents on a single platform, connected to your systems, with a Growth Ops team that builds it with you, maintains it and adds one process after another. Six reasons:

  • Every connection arrives with the process that uses it. Your marketplace orders, your ERP stock and your invoicing system's documents go into a database that cross-references them, the workflows apply your rules and your team resolves exceptions in an App built for that process. What matches runs on its own, and what takes judgment reaches the person who resolves it, with full context.
  • It connects through whatever path each system offers and writes back. Native connectors for WooCommerce, Multivende, Mercado Libre and Bsale, among others; for everything else, the API over HTTP or with Python, events by webhook, the ERP's database or files over FTP. Puente executes the action where it belongs: stock in Multivende, the price in your store or the label and tracking number on the order.
  • The team that built it keeps it up to date. When an API changes, a credential expires or your operation asks for a new rule, the Growth Ops team adapts the process and publishes it as a new version, with the same webhook and the same schedule. At the pet retailer from Example 3, each of its 167 versions is a change that reached production.
  • What gets built is written down on the platform, visible to your team. The rules live explicitly in each workflow, every version stores its author and date, every run records which step it stopped at and why, and each app accesses only the tables it is allowed to. Rolling back means activating the previous version.
  • Each process reaches production in 2 to 4 weeks, and the next one is added on the same connections. You start with the integration that hurts most and continue with reconciliation, shipping or margin, on the same data.
  • Results are measured in production. The figures in the three examples come from each customer's production tables: orders labeled with no human intervention, incidents and their resolution time, margin by sales line and delivery promise compliance.

Custom middleware connects your systems precisely. Puente OS builds that connection, the full process that runs on it and the team that keeps it up to date as your operation grows.

When does each one make sense?

Custom middleware fits when you have an in-house engineering team that wants to build, run and own the integration, or when your core system is so particular that the connection is part of what sets you apart. Puente OS fits when you want the full process running and a team that keeps it connected as your systems change.

  • Custom middleware, if you have engineers with time to maintain it, a heavily customized ERP or in-house system, a policy that requires the code to run on your infrastructure or a narrow connection: an integration agency estimates a custom connector is enough for 2 to 4 flows. It is the option that gives you full control of the code and its roadmap.
  • Puente OS, if your team moves data between systems by hand, if your integrations carry rules nobody wrote down or stop often, or if the connection is the first step of a process you want running on its own: reconciliation, shipping, margin or invoicing. Also if you want to add processes on the same connections, with a team that builds them with you and maintains them.
  • Both, when you already have a custom integration that works and someone who maintains it. Puente reads from the systems that integration syncs, through their API or their database, and builds the next process on top.

How do you start?

With a narrow process that hurts, with volume and manual handoffs. The risk of a software project grows with its size. The Standish Group's CHAOS Report 2015, covering over 25,000 software projects, found that 61% of small projects succeeded, against 11% of large ones and 6% of very large ones, and calls size the single most important factor in the outcome. These are software projects in general, and the conclusion holds for an integration: start small and deliver fast.

That's why Puente OS moves one process at a time, and each one reaches production in 2 to 4 weeks.

  1. Pick the process. With volume, manual handoffs and a visible impact when it fails: order sync between your largest marketplace and your ERP is usually a good place to start.
  2. Inventory the integrations already running. Which systems each one connects, who maintains it, where its documentation lives and what happens when it fails. That list defines what gets connected, what gets rebuilt and what stays as it is.
  3. Take the baseline. Hours of manual handoffs per week, errors per month and recovery time when an integration stops.
  4. Connect the sources. With the native connector when one exists, and otherwise through the API, a webhook, the system's database or a file.
  5. Write down the rules your team applies from memory. For example: "if a marketplace order still hasn't appeared in the ERP two hours after coming in, it goes to operations with the full order in view."
  6. Decide where each exception goes. The system resolves it, or it reaches a named person with full context in an App.
  7. Measure from the first week and add the next process on the same connections.

That is autonomous operations design applied to your integrations: the repeatable work runs on its own, on your rules, and your team decides what takes judgment. To choose which steps run on a workflow and which go to an agent, this guide on how to implement AI in your business can help. If you sell on marketplaces with an integrator at the center, the same approach is in Puente OS vs Multivende, and if you're evaluating a workflow automation platform, in this comparison.

Your ERP records what happened. Your BI shows you what happened. Puente makes it happen. We believe every company in Latin America can be operationally autonomous, and that starts with your systems talking to each other on their own, on your rules, with a team that keeps them connected.

Key takeaways

  • Custom middleware is the integration your team, a freelancer or a software development agency builds to connect ERP, eCommerce, marketplaces, WMS and invoicing: it gives full control of the code and fits your system exactly.
  • Building an eCommerce-ERP connector takes 6 to 12 weeks according to an agency estimating the Amsterdam market, and 8 to 16 according to a connector provider. Then maintenance begins: Shopify releases an API version every three months, Mercado Libre's access token expires after 6 hours and Bsale changed its API in 11 of the 12 months of 2025.
  • An integration's continuity depends on how much of what is known gets written down: across 133 popular GitHub projects, 65% have a truck factor of 2 or less.
  • Puente OS builds the connection inside the full process that uses it, with apps, workflows, databases and agents on a single platform, version history and a record of every run.
  • The Growth Ops team builds each process and maintains it when an API, a channel or a format changes. At an electronics seller in Mexico, between August 1 and 12, 2026, 0.59% of orders had an operational incident, with a median resolution time of 10 minutes.
  • Custom middleware fits with an in-house engineering team and a very particular core system. Puente OS fits when you want the process running end to end, in 2 to 4 weeks per process.

Have custom integrations and want to see which part of your operation can run on its own? Let's talk about your processes, and we'll show you Puente OS running with cases like the ones in this article. Book a conversation with our team.

Frequently asked questions

What is middleware?

Middleware is software that sits between two or more systems and lets them exchange data: it translates formats, moves records from one system to another and keeps information in sync. In a retail or eCommerce operation, it connects the ERP with the online store, the marketplaces, the WMS, the courier and the invoicing system. It can be custom-built, by an in-house team, a freelancer or a software development agency, or assembled on an integration platform (iPaaS). Puente OS builds those connections as part of the full process that uses them, with apps, workflows, databases and agents.

How long does an ERP-eCommerce integration take?

An agency that builds these connectors estimates, for the Amsterdam market, 6 to 12 weeks: 2 weeks of data mapping, 3 to 6 of development and 2 to 4 of testing. By ERP, it estimates 6 to 8 weeks for Odoo 17 or 18, 8 to 10 for Sage 100 or 200 and 10 to 12 for Sage X3. A connector provider says most Shopify-ERP integrations take 8 to 16 weeks. These are figures from Europe and the United States. With Puente OS, each process reaches production in 2 to 4 weeks, connection included.

What happens if my ERP's or marketplace's API changes?

The integration has to adapt, and those changes are frequent: Shopify releases a new API version every three months, VTEX discontinued its legacy Webservice API in 2025, Bsale logged API changes in 11 of the 12 months of 2025 and Mercado Libre's access token expires every 6 hours. In a custom integration, whoever holds maintenance makes the adjustment. In Puente OS, the run history shows which step a process stopped at and why, failure alerts include an excerpt of the error and the Growth Ops team adapts the connection. The workflow's new version inherits the same webhook and the same schedule, and if something goes wrong, rolling back means activating the previous version.

Does Puente OS replace my current integration?

It can take it over or run alongside it. If your integration works and someone maintains it, Puente reads from the systems it syncs and builds the next process on top. If its logic is undocumented or it stops often, the Growth Ops team can rebuild that connection inside Puente OS, with its version history, a record of every run and a team that maintains it. The decision is made when mapping the process, with the inventory of what's already running: what each integration connects, who maintains it and what happens when it fails.

Does Puente OS connect to my ERP?

Yes, through whatever path your ERP offers. Puente OS has native connectors for systems like WooCommerce, Multivende, Mercado Libre and Bsale. For the rest, the Growth Ops team connects with a workflow that calls the API over HTTP or with Python, receives its events by webhook, reads its database when the ERP grants that access or takes its files. With SAP Business One, for example, Puente reads the ERP's database in production with a Python workflow that runs every day. Which path fits depends on the access your ERP provides, and it's defined when mapping the process.

What is an integration's bus factor?

The bus factor, also called the truck factor, is the minimum number of people who would have to leave a project for it to stall. Across 133 popular GitHub projects, a 2016 study found that 65% have a truck factor of 2 or less. In an integration, it measures how many people understand how it works, and it rises with up-to-date documentation, explicitly written rules and two or more people who know the system. In Puente OS, what gets built stays on the platform: the rules written in each workflow, the version history and the record of every run, with the Growth Ops team in charge of maintaining it. That's why at Puente one person builds and maintains dozens of processes: what they know is written down on the platform, visible to the Growth Ops team.

External sources cited

Some of these sources are in Spanish (Bsale, Defontana and Mercado Libre), and quotes from them are our translation. Everything this post says about the industry and the platforms comes from official documentation, academic studies or vendor publications, reviewed on October 11, 2026. Kolonell, Webgility, Ampersand, OpusGo and Sana Commerce sell integrations, connectors or integration infrastructure: their estimates serve as industry context, and from Kolonell we cite only timelines and types of maintenance. The bus factor studies and the GitHub survey measure open source projects, and the Standish figures cover software projects in general. Puente OS customer figures are production measurements as of August 2026; label generation time and the request dates for each process come from follow-up with the customer.

Integration timelines and maintenance

Platform and ERP APIs

Documentation and software projects

See Puente OS in your operation

Let's talk about your processes, and we'll show you Puente OS running.

Sign up
Back to resources