Sarah Carnevali Semtchuk; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202601442

Artículo elaborado por la herramienta ResumeAI, solución de inteligencia artificial desarrollada por el Instituto Pecege orientada a la síntesis y redacción.

Resumen

Las Interfaces de Programación de Aplicaciones (APIs) se han consolidado como activos estratégicos en marketplaces, transicionando de funciones técnicas a pilares de integración externa y vectores de generación de ingresos. El objetivo de este trabajo fue analizar y comparar las arquitecturas de marketplaces, con foco en los módulos de catálogo, autenticación, límites de acceso y eventos, investigando cómo estos componentes técnicos se rentabilizan en el escenario actual. La investigación adoptó un enfoque cualitativo, propositivo y descriptivo, utilizando un estudio de múltiples casos que comparó marketplaces tradicionales (Amazon y eBay) con plataformas de quick commerce (iFood y 99Food). Se realizó una revisión bibliográfica sistemática y una investigación documental en portales de desarrolladores, analizando patrones de monetización y arquitectura. Los resultados evidenciaron que las APIs se han convertido en productos, con modelos de monetización que varían significativamente: mientras las plataformas de quick commerce priorizaron la penetración de mercado a través de modelos gratuitos, los marketplaces tradicionales establecieron cobros basados en suscripciones y uso. Arquitectónicamente, la eficiencia operativa y la escalabilidad de las integradoras dependieron de la migración a una Arquitectura Orientada a Eventos (EDA), sustituyendo consultas repetitivas (polling) por mecanismos de notificación push (webhooks). Se observó que la adopción de EDA, especialmente para el módulo de Catálogo, ofreció mayor eficiencia y consistencia en la integración. Se propuso un modelo híbrido de monetización (suscripción y pago por uso) y una arquitectura conceptual con módulos de API Management, Events y Catalog. Se concluyó que la combinación de una arquitectura resiliente y modelos de monetización bien estructurados crea un ciclo positivo de ingresos e innovación, justificando el cobro por el valor agregado y promoviendo operaciones más eficientes y sostenibles.

Palabras clave: Arquitectura orientada a eventos; Economía de APIs; Gestión de APIs; Plataformas digitales; Webhooks.

1. Introducción

La era digital ha estado marcada por el auge y la consolidación de plataformas de ventas virtuales, conocidas como marketplaces, que han transformado la dinámica del comercio y la interacción entre empresas y consumidores. Al centralizar diversos canales de venta, estas plataformas facilitan la usabilidad y agilizan las operaciones, ampliando el alcance y potenciando las ventas (Jacobson y Woods, 2012). En este escenario de intensa digitalización, las Interfaces de Programación de Aplicaciones (APIs) han emergido como elementos cruciales, trascendiendo su función inicial de meras herramientas técnicas para convertirse en activos estratégicos. Actúan como pilares esenciales para la integración externa y como vectores fundamentales para la generación de ingresos, impulsando la llamada “Economía de APIs” (Gunturu, 2022). La adopción de una estrategia “API-first” permite a las empresas optimizar procesos internos, crear plataformas escalables y ampliar su alcance tecnológico, generando nuevos flujos de ingresos y mejorando la experiencia del cliente (Johnson Mary, 2025). La relevancia de las APIs se ve subrayada por el crecimiento del comercio electrónico y la demanda de conectividad, lo que las hace indispensables para la competitividad en el mercado actual.

La transición de una API de interfaz técnica a un activo comercializable se encapsula en el concepto de “API-as-a-Product”. Este enfoque redefine la API no solo como un componente de software, sino como un producto con valor de negocio medible, diseñado para resolver problemas específicos de los usuarios (Eaton et al., 2024). A diferencia de una API interna, una API como producto requiere gestión del ciclo de vida, enfoque en la calidad, usabilidad y soporte al cliente (Jacobson et al., 2011). La monetización de APIs, por su parte, es la práctica de generar ingresos al otorgar acceso controlado a servicios y funcionalidades empresariales, representando la etapa final de esta “producción” (Edi Labs, 2024). Existen cuatro estrategias principales de monetización de APIs, según Solanke y Liang (2022): el modelo de suscripción (“Subscription-Based”) para acceso continuo (Chugh, 2026; Verma et al., 2025); el pago por uso (“Pay-Per-Use”) que cobra proporcionalmente al consumo real (Gebauer et al., 2017); el modelo “Freemium” que ofrece acceso básico gratuito para atraer una amplia adopción (Hsu et al., 2025); y el reparto de ingresos (“Revenue-Sharing”) que remunera al proveedor de la API con un porcentaje de los ingresos generados por terceros (Prado, 2025; Qwist Research, 2026). La elección del modelo debe equilibrar la innovación y la viabilidad financiera (Onipede, 2024).

Paralelamente a la evolución de los modelos de negocio, las elecciones arquitectónicas desempeñan un papel decisivo en la eficiencia operativa y la escalabilidad de los marketplaces. Tradicionalmente, muchos sistemas dependen del modelo de consulta repetitiva (“polling”), donde los clientes verifican periódicamente el servidor en busca de actualizaciones. Este enfoque genera un tráfico de red voluminoso y redundante, aumentando la latencia y el consumo de recursos, lo que resulta insostenible en ecosistemas de alta demanda (Richardson, 2018). En contrapartida, la Arquitectura Orientada a Eventos (EDA) representa un avance significativo, sustituyendo el “polling” por mecanismos de notificación “push”, como los *webhooks*. Conforme detallado por Hohpe y Woolf (2003), la EDA se basa en patrones de mensajería que permiten al marketplace enviar actualizaciones críticas a los sistemas integrados tan pronto como ocurre un cambio relevante. Este enfoque promueve el desacoplamiento entre servicios, asegura la consistencia eventual de los datos y mejora la capacidad de respuesta del ecosistema. La implementación de *webhooks* en módulos críticos, como el de catálogo, puede optimizar el consumo de recursos y la integridad de la oferta, en lugar de exigir verificaciones constantes. Esta eficiencia arquitectónica mejora la experiencia del socio y justifica la monetización por el valor agregado y el rendimiento superior.

La creciente complejidad de los marketplaces y la evolución de las APIs para activos estratégicos monetizables exigen la comprensión de los matices arquitectónicos y de los modelos de negocio que sustentan esta transformación. La brecha en la literatura y en las prácticas de mercado, especialmente en cuanto a la rentabilización de componentes técnicos y la adopción de arquitecturas orientadas a eventos, justifica la presente investigación. El objetivo de este trabajo fue analizar y comparar las arquitecturas de marketplaces, con foco en los módulos de catálogo, autenticación, límites de acceso y eventos, investigando cómo estos componentes técnicos se rentabilizan en el escenario actual.

2. Material y Métodos

La presente investigación fue delineada bajo un enfoque cualitativo, buscando profundizar la comprensión sobre los fenómenos estudiados a través del análisis de datos no numéricos y la interpretación de contextos específicos. Se caracterizó como una investigación propositiva, ya que tuvo como finalidad la elaboración de modelos prácticos de monetización y arquitectura de Interfaces de Programación de Aplicaciones (APIs), y descriptiva, al detallar las características de los marketplaces y sus APIs. Se adoptó el estudio de múltiples casos como método central, permitiendo un análisis comparativo robusto.

El contexto del estudio se centró en el análisis de plataformas de ventas digitales, conocidas como marketplaces, y en la evolución de las Interfaces de Programación de Aplicaciones (APIs) como activos estratégicos. La unidad de análisis consistió en las arquitecturas y los modelos de monetización de APIs implementados por estas plataformas, con enfoque en módulos específicos como catálogo, autenticación, límites de acceso y eventos. La investigación se realizó considerando el escenario actual de digitalización del comercio electrónico, abarcando información disponible hasta el año 2026, según la fecha de finalización del trabajo.

La muestra de estudio se dividió intencionalmente en dos grupos distintos para permitir un análisis comparativo en profundidad. El primer grupo estuvo compuesto por “marketplaces” tradicionales que ya poseían APIs monetizadas, seleccionados por su relevancia global y por presentar modelos de negocio y arquitectura consolidados. Se incluyeron en este grupo las plataformas Amazon y eBay, reconocidas por sus ecosistemas de desarrolladores y por la claridad en sus patrones de monetización e integración de APIs.

El segundo grupo de la muestra comprendió “marketplaces” del segmento de “Quick Commerce”, caracterizados por la entrega ultrarrápida y la conveniencia. La selección de estas plataformas tuvo como objetivo investigar el potencial de monetización de sus APIs, que, en el momento de la investigación, no eran directamente monetizadas, e identificar oportunidades arquitectónicas. Se analizaron iFood y 99Food, ambos con fuerte actuación en el escenario brasileño, cuyas documentaciones públicas de APIs permitieron la evaluación de sus estructuras y la identificación de lagunas de valor.

La recopilación de datos comenzó con una revisión bibliográfica sistemática, centrada en conceptos fundamentales para la investigación. Se exploraron temas como “API-as-a-Product”, que aborda la API como un producto con valor de negocio, la “API Economy”, que describe el ecosistema comercial impulsado por APIs, y los diversos modelos de monetización, incluyendo suscripción, pago por uso, freemium y reparto de ingresos. Los datos se extrajeron de literatura especializada, trabajos de conferencias y repositorios de datos abiertos, según la metodología de Treinta et al. (2013).

En paralelo a la revisión bibliográfica, se realizó una investigación documental exhaustiva sobre las plataformas seleccionadas. Esta etapa implicó el análisis de material público proporcionado por las empresas, como sus portales de desarrolladores, documentaciones oficiales de APIs y términos de servicio. El objetivo fue obtener información detallada sobre la implementación práctica de las APIs y sus respectivos modelos de negocio, complementando la base teórica con datos del mundo real.

Durante la investigación documental, se recopiló información específica sobre la estructura de los endpoints y los recursos ofrecidos por las APIs de cada marketplace. Se evaluó la presencia e implementación de arquitecturas orientadas a eventos, como el uso de webhooks, en contraste con modelos de consulta repetitiva. Adicionalmente, se levantaron los modelos de precios y los planes de integración disponibles, buscando comprender las estrategias de monetización y las condiciones de acceso para desarrolladores y socios.

Las etapas de ejecución de la investigación se organizaron de forma secuencial y complementaria. Inicialmente, se procedió con la revisión bibliográfica sistemática para establecer el marco teórico y conceptual. A continuación, y de manera simultánea en algunos momentos, se realizó la investigación documental, que permitió la recopilación de datos empíricos directamente de las fuentes primarias de las empresas analizadas. Este enfoque combinado garantizó una base sólida de conocimiento teórico y práctico para el análisis subsiguiente.

Tras la recopilación, los datos se sometieron a un análisis comparativo de contenido, técnica que permitió identificar y contrastar patrones y características relevantes entre los diferentes marketplaces. El foco principal del análisis fue mapear las estrategias de monetización y las arquitecturas de API adoptadas, buscando comprender las similitudes y diferencias entre los grupos de “marketplaces” tradicionales y de “Quick Commerce”. Esta metodología posibilitó la identificación de tendencias y particularidades en cada segmento.

Específicamente en el análisis de monetización, se compararon variables cruciales que determinan el valor y el costo de las APIs. Se examinaron los modelos de fijación de precios, el volumen de uso permitido y los recursos limitados, como los límites de peticiones y la cantidad de datos accesibles a través de las APIs. Esta comparación detallada permitió identificar cómo cada marketplace estructura su oferta de valor y las condiciones para el acceso y uso de sus interfaces, revelando los enfoques para la generación de ingresos.

El análisis arquitectónico se centró en la propuesta de valor de los módulos de Catálogo, Autenticación, Límites de Acceso (Rate Limits) y Eventos. Se investigó la implementación de mecanismos de “pooling” versus “push” de webhooks para la comunicación de eventos, evaluando la eficiencia y la resiliencia de cada enfoque. El objetivo fue identificar las “brechas” de valor existentes en las arquitecturas actuales y las oportunidades de monetización que podrían surgir de la optimización de estos componentes técnicos en los dos grupos de marketplaces estudiados.

Con base en los análisis realizados, se elaboró una propuesta de modelo de monetización y arquitectura para marketplaces que buscan rentabilizar sus APIs. Se sugirió un modelo híbrido de monetización, que combina diferentes estrategias de cobro, justificándose por el valor agregado y por las ganancias de rendimiento proporcionadas por la adopción de arquitecturas orientadas a eventos. Adicionalmente, se esbozó una arquitectura conceptual para la implementación de webhooks, detallando las implicaciones técnicas necesarias para la integración eficiente de los socios en el ecosistema de la plataforma.

3. Resultados y Discusión

La evolución de las Interfaces de Programación de Aplicaciones (APIs) de meras herramientas técnicas a activos estratégicos de negocio es un fenómeno central en la economía digital contemporánea, reflejando una transformación profunda en la forma en que las empresas operan y generan valor. Este movimiento, denominado “API Economy” por Gunturu (2022), describe un ecosistema comercial vibrante donde las organizaciones exponen sus activos digitales, como datos y funcionalidades, a socios y terceros, creando nuevos flujos de valor e impulsando la innovación. La transición de una visión puramente técnica a un enfoque estratégico de “API-as-a-Product” es crucial para que las empresas no solo sobrevivan, sino que prosperen en este escenario dinámico.

El concepto de “API-as-a-Product” (API como Producto), tal como lo articula Eaton et al. (2024), implica que una API debe diseñarse para resolver un problema específico de un usuario, ya sea un desarrollador o una empresa, poseyendo un ciclo de vida propio, una estrategia de mercado bien definida y un valor medible. A diferencia de una API interna, que puede considerarse un subproducto de un sistema mayor, una API externa, cuando se trata como producto, exige el mismo rigor de gestión que un software comercial, como un “Software as a Service” (SaaS). Esto significa un enfoque intenso en la calidad, usabilidad, soporte al cliente y, fundamentalmente, en la experiencia del desarrollador, como enfatizan Jacobson, Brail e Iyver (2011). Una excelente documentación, facilidad de integración y alta confiabilidad son pilares para la atracción y adopción de la API, independientemente de la complejidad técnica subyacente. La monetización, en este contexto, no es solo una decisión financiera, sino la etapa final de esta “producción”, donde los activos digitales internos se convierten en fuentes de ingresos sostenibles, superando las complejidades de fijación de precios (Edi Labs, 2024). Esta madurez organizacional en la gestión de APIs permite mitigar riesgos de obsolescencia y capturar valor económico real en los ecosistemas.

En cuanto a los modelos de monetización de APIs en marketplaces, la investigación identificó cuatro estrategias principales, según Solanke y Liang (2022): suscripción (“Subscription-Based”), pago por uso (“Pay-Per-Use”), “freemium” y reparto de ingresos (“Revenue-Sharing”). Cada uno de estos modelos tiene características distintas y es más adecuado para diferentes contextos de negocio y tipos de servicio. El modelo de suscripción, por ejemplo, se basa en una tarifa recurrente para el acceso continuo a un producto o servicio, estableciendo una relación duradera entre proveedor y cliente (Chugh, 2026). Sus ventajas incluyen un menor costo inicial y previsibilidad, lo que reduce la barrera de entrada para los usuarios. Este modelo es particularmente eficaz para productos de uso frecuente que reciben actualizaciones y mejoras constantes, como software, infraestructura digital y accesos a plataformas, como señalan Verma et al. (2025). La previsibilidad de los ingresos para el proveedor y del costo para el consumidor lo hace atractivo para servicios esenciales y de valor consistente.

En contraste, el modelo de pago por uso (“Pay-Per-Use”) remunera al proveedor en función del consumo real del servicio, alineando el cobro a la utilidad efectiva. Este patrón es ideal para servicios de alto volumen, como pasarelas de pago, y permite mayor personalización y escalabilidad para el cliente, que paga solo por lo que utiliza. Sin embargo, su implementación exige sistemas de monitoreo en tiempo real extremadamente robustos y precisos para controlar el flujo de demanda y garantizar la viabilidad del modelo, como destacado por Gebauer et al. (2017). La complejidad técnica y arquitectónica para rastrear y facturar el uso granular puede ser un desafío significativo, pero los beneficios en términos de flexibilidad y alineación con el valor entregado justifican la inversión.

El modelo “freemium” representa una estrategia híbrida, ofreciendo una capa de servicios esenciales de forma gratuita para atraer una amplia base de usuarios, mientras que funcionalidades avanzadas, características premium o accesos sin restricciones se comercializan (Chugh, 2026). En entornos de plataforma y ecosistemas digitales, este enfoque es poderoso para mitigar barreras de entrada y acelerar el “efecto de red” (“network effects”), maximizando la liquidez y el valor percibido de la plataforma. La monetización ocurre por la conversión estratégica de usuarios comprometidos que demandan mayor capacidad productiva o soporte especializado (Hsu et al., 2025). Este modelo es particularmente relevante para marketplaces que buscan expandir rápidamente su base de socios antes de introducir cobros directos.

Finalmente, el modelo de “Revenue-Sharing” (compartición de ingresos) es ampliamente difundido en plataformas a gran escala, como Mercado Libre, donde el proveedor de la API recibe un porcentaje de los ingresos generados por terceros que utilizan la API para habilitar transacciones o servicios lucrativos (Prado, 2025). La integración vía API permite que estas plataformas capturen el valor de cada transacción en tiempo real, y el modelo escala conforme al éxito del vendedor, alineando los intereses financieros de todos los participantes. Además de las comisiones, los marketplaces modernos utilizan APIs para ofrecer servicios de valor agregado, como crédito y anticipación de cuentas por cobrar, transformando costos operativos en nuevas líneas de ingresos y la plataforma en un proveedor de infraestructura financiera (Qwist Research, 2026). Este enfoque permite la implementación de modelos de pago por uso o niveles de suscripción para funcionalidades que aumentan la conversión, como el cálculo de flete inteligente o la integración con sistemas de ERP. La complejidad de los modelos de monetización se profundiza cuando el marketplace actúa como un entorno donde los socios pueden vender sus propios softwares vía SaaS, monetizando no solo el acceso a la API, sino también la infraestructura y el ecosistema que ofrece, como se ejemplifica con la Amazon Selling Partner API (2025).

El análisis del módulo de Catálogo reveló diferencias significativas entre los marketplaces de “Quick Commerce” y los tradicionales, reflejando sus distintas lógicas de negocio y prioridades arquitectónicas. En las plataformas de “Quick Commerce”, como iFood y 99Food, la volatilidad de los datos y la granularidad de la jerarquía del menú son elevadas, dada la prioridad del modelo hiperlocal y la disponibilidad inmediata. La entidad raíz en estos sistemas es la tienda (“merchant”), haciendo la oferta única y personalizable. Técnicamente, un artículo de una unidad no comparte identificadores o atributos con el de otra, incluso si son productos similares, lo que exige sistemas de bajísima latencia para garantizar la consistencia en tiempo real entre el inventario físico y el escaparate digital.

En iFood, la arquitectura del catálogo, como se ilustra en la Figura 1, sigue el patrón REST con payloads JSON, estructurada en tres niveles: Categorías, Ítems y Grupos de Complementos (Modificadores). La entidad Producto actúa como el registro maestro de información esencial, como nombre, descripción, código de barras (EAN) e imágenes. El Producto es agnóstico a la venta hasta que se instancia como Ítem (vinculado a una Categoría para su visualización) o como Complemento (asociado a un Grupo de Complementos para su personalización). Mientras que el Producto posee propiedades intrínsecas, el Ítem y el Complemento cargan propiedades transaccionales, como precio y disponibilidad, que pueden variar por canal. Esta estructura, aunque flexible para la personalización de menús locales, impone desafíos en la gestión de datos y en la escalabilidad para integradores que operan con múltiples comerciantes, ya que la granularidad y la volatilidad exigen actualizaciones frecuentes y precisas para mantener la consistencia entre el inventario físico y el digital. La necesidad de gestionar variaciones de precio y disponibilidad a nivel de ítem y complemento, por canal, aumenta la complejidad de la lógica de integración para los socios.

Figura 1. Esquema de las entidades que componen la arquitectura del catálogo de iFood

Fuente: Resultados originales de la investigación

99Food, por su parte, adopta una arquitectura orientada a la oferta, pero sin la entidad Producto, reutilizando la entidad Item. El rol del objeto se define por el atributo “is_sold_separately”: si es “true”, el Item se ofrece individualmente; si es “false”, actúa solo como modificador dentro de un grupo (“Modifier Group”). Un punto crítico de este formato es que los cambios de estado son globales, imposibilitando inactivar un ítem en la venta directa y mantenerlo activo como modificador. Esta estructura, esquematizada en la Figura 2, simplifica el modelado al reducir el número de entidades, pero introduce una rigidez en la gestión de disponibilidad que puede ser problemática para los comerciantes que desean flexibilidad en la oferta de productos. Por ejemplo, un ítem que es un modificador (como una salsa) no puede venderse por separado si su estado es “false” globalmente, limitando las estrategias de venta del comerciante.

Figura 2. Esquema de las entidades que componen la arquitectura de catálogo de 99Food

Fuente: Resultados originales de la investigación

En cuanto a los endpoints, iFood ofrece una gama más amplia de operaciones CRUD granulares (Catálogo, Categoría, Ítem, Complemento), que, aunque requieren un mayor control de las integradoras, son más performáticas. Para simplificar, el endpoint PUT /items permite una estrategia de “escritura atómica”, actualizando todo el árbol de dependencias en una única solicitud, lo que reduce llamadas de red (“round-trips”), pero puede generar picos de latencia en catálogos extensos debido a la validación de esquemas complejos. 99Food, en contrapartida, adopta un enfoque minimalista y orientado a la sincronización de estado, con recuperación de datos vía endpoints GET de lectura del catálogo completo y escritura vía payloads densos en “Bulk Update”. Esto simplifica la lógica de la integradora, eliminando la gestión del orden de creación de dependencias, pero, al igual que en iFood, esta centralización genera sobrecarga de procesamiento y aumento de latencia cuando solo atributos simples, como el precio, necesitan ser modificados. La Tabla 7, aunque no incluida en la selección final, detalla la equivalencia entre los endpoints de ambas plataformas, evidenciando los diferentes enfoques para la gestión del catálogo.

A diferencia de estos, los marketplaces tradicionales, como Amazon y eBay, operan bajo una lógica de indexación global y búsqueda escalable. La entidad central es el Producto industrializado, utilizando códigos globales como “Stock Keeping Unit” (SKU), en una relación de N:N (un artículo para múltiples vendedores). El enfoque reside en la estandarización técnica y la navegabilidad en taxonomías profundas, permitiendo filtros precisos y comparación de precios entre diferentes ofertas del mismo producto. Este enfoque es fundamental para ecosistemas de gran escala, donde la consistencia y la estandarización se valoran más que la personalización hiperlocal.

La gestión del catálogo en Amazon se divide en cuatro módulos: “Catalog Items API”, “Product Type Definition API” y “Listing Items API”. La “Catalog Items API” permite el descubrimiento en el repositorio global vía EAN o nombre, devolviendo el “Amazon Standard Identification Number” (ASIN), esencial para el proceso de “matching”, donde el vendedor asocia su oferta a un producto ya catalogado. La “Product Type Definitions API” proporciona dinámicamente el esquema en JSON con los requisitos de validación para cada categoría, evitando esquemas rígidos para millones de tipos de artículos y reduciendo errores de procesamiento síncrono. Finalmente, la “Listing Items API” gestiona las ofertas del vendedor (“Seller”), permitiendo manipulación granular vía PUT (actualización total) o PATCH (actualización parcial), resolviendo problemas de concurrencia y controlando el ciclo de vida de la oferta. La Figura 3 ilustra la conexión entre las entidades de Amazon, donde la combinación de marca, producto y variaciones resulta en el “Child ASIN”, que, integrado al inventario del vendedor, se convierte en un “Listing Item” con condiciones comerciales de oferta. Esta arquitectura compleja, pero robusta, garantiza la integridad de los datos en un ecosistema global y altamente escalable. La capacidad de definir dinámicamente esquemas de datos es una ventaja significativa, ya que permite que la plataforma se adapte a nuevas categorías de productos sin requerir grandes refactorizaciones, un desafío común en sistemas legados.

Figura 3. Esquema de las entidades que componen la arquitectura de catálogo de Amazon

Fuente: Resultados originales de la investigación

eBay, con su “Inventory API”, adopta una premisa híbrida, separando el inventario (“Inventory Item”) de la publicación comercial (“Listing”). Mientras que en Amazon la oferta es intrínseca al ASIN, en eBay el desarrollador crea un “Item” propio por tienda y lo vincula a un “eBay Product Identifier” (ePID) para relevancia, buscando la organización para el usuario, pero manteniendo la necesidad de registrar metadatos individuales por tienda. El “Item” almacena datos técnicos, SKU del vendedor, inventario y precio, mientras que el “Listing” contiene reglas de negocio como políticas de envío y exhibición de la oferta. eBay permite anuncios heterogéneos a través de “Aspects” (metadatos descriptivos), y la gestión exige un flujo de tres etapas: creación del “item”, creación de la oferta y publicación, otorgando control de estado granular. La Figura 9, aunque no incluida en la selección final, esquematiza esta relación, mostrando cómo eBay equilibra la flexibilidad para los vendedores con la necesidad de organización para los compradores.

En resumen, mientras que el “Quick Commerce” se enfoca en la sincronización de estado y en modificadores dinámicos para atender la volatilidad de la operación local, el marketplace tradicional prioriza la gobernanza de metadatos y la escalabilidad de búsqueda global a través de identificadores únicos (ASIN/ePID). Esta estructuración de catálogo define las reglas de “qué” se está vendiendo, pero la eficiencia operacional de la integración depende de “cómo” se estructuran los endpoints y cómo estos cambios en los datos se comunican entre las plataformas externas e internas.

El módulo de Eventos es la capa de comunicación reactiva y asíncrona de las APIs, esencial para la escalabilidad de marketplaces de alto rendimiento, sustituyendo el modelo de consultas repetitivas (“polling”) por una Arquitectura Orientada a Eventos (EDA), según lo detallado por Hohpe y Woolf (2003). Este enfoque, basado en patrones de mensajería, permite al marketplace enviar (“push”) actualizaciones críticas a los sistemas integrados cada vez que ocurre un cambio relevante. Este módulo garantiza la consistencia eventual entre sistemas distribuidos y promueve el desacoplamiento entre servicios, asegurando la responsividad del ecosistema de manera eficiente (Richardson, 2018).

El análisis de este módulo revela que la diferencia fundamental entre “Quick Commerce” y los marketplaces tradicionales no reside solo en el protocolo, sino en el modelo de entrega y la criticidad de la latencia. El “Quick Commerce” exige una respuesta casi instantánea para la sincronización, siendo la arquitectura predominantemente basada en “Webhooks HTTP”. En este modelo, el marketplace actúa como un cliente que realiza solicitudes POST a un endpoint predefinido por la integradora, exigiendo que este sea altamente disponible. La baja latencia es crucial para la experiencia del usuario, donde la disponibilidad de productos y precios debe actualizarse en milisegundos. Sin embargo, la persistencia de eventos es generalmente efímera, dependiendo de reintentos, lo que puede llevar a la pérdida de datos en caso de fallo prolongado del endpoint de la integradora.

Por otro lado, el marketplace Tradicional prioriza la durabilidad y la ordenación de eventos a gran escala. Debido al volumen masivo y a la posibilidad de una mayor latencia, plataformas como Amazon pueden ofrecer opciones más robustas que simples “Webhooks”, integrándose directamente a servicios en la nube como “AWS SQS” o “Amazon EventBridge”. En este modelo, el integrador no necesita exponer un endpoint público y garantizar su alta disponibilidad, solo consumir los mensajes de una cola que queda almacenada con mayor persistencia y sin riesgo de pérdida de eventos en caso de indisponibilidad. La Tabla 1 compara las características de estos diferentes modelos de notificación.

Tabla 1. Comparación de las características de los diferentes tipos de sistemas de notificación

Atributo	iFood, 99Food y eBay	Amazon
Procedimiento	“Webhooks (HTTP/HTTPS)”	“SQS”, “EventBridge”
Flujo de datos	“Push” (El marketplace envía)	“Pull”/”Reactivo” (El sistema consume de la cola)
Latencia	Milisegundos a pocos segundos	Segundos a minutos (tolerable)
Persistencia de eventos	Generalmente efímera (depende de reintentos)	Alta (mensajes persistidos en colas)
Complejidad de infraestructura	Baja (solo requiere un servidor web)	Media/Alta (muestra infra de nube o “polling” de cola)

Fuente: Resultados originales de la investigación

La Tabla 1 ilustra claramente los trade-offs: mientras que los Webhooks (HTTP/HTTPS) ofrecen latencia de milisegundos, su persistencia es efímera. En contraste, los sistemas basados en colas de nube (SQS, EventBridge) pueden tener latencia de segundos a minutos, pero garantizan alta persistencia de eventos. La complejidad de infraestructura para Webhooks es baja (exige solo un servidor web), mientras que para sistemas de nube puede ser media/alta, dependiendo de la infraestructura y del modelo de “polling” de la cola. Esta comparación es vital para la elección arquitectural, que debe alinearse a las necesidades de negocio y a los requisitos de resiliencia.

En iFood, el mantenimiento de la consistencia de datos entre el marketplace y sistemas externos como los ERP revela una dependencia del modelo de “polling” en la mayoría de los módulos, con la excepción del módulo de Pedidos que tiene integración con “Webhooks HTTPS”. Esta arquitectura de “extracción de datos” genera un tráfico voluminoso y redundante, evidenciando una brecha tecnológica para la transición hacia un modelo “API-First” orientado a eventos. La implementación de “Webhooks” de catálogo transformaría esta dinámica, sustituyendo la verificación constante por notificaciones reactivas de alteración, optimizando el consumo de recursos y la integridad de la oferta. 99Food, en contraste, presenta una estructura de eventos más capilarizada y ligada a “Webhooks”, extendiendo la reactividad más allá del módulo de “Order” y abarcando los módulos de “Store”, Menu y “Logistics”. Este enfoque demuestra una estructura de gestión de estados asíncronos y masivos, permitiendo que el sistema externo reaccione inmediatamente a procesos de “Backoffice” que, en modelos de “polling”, requerirían una orquestación compleja de solicitudes.

En el ecosistema de Amazon, la estrategia de mensajería evoluciona hacia una integración nativa con infraestructuras de nube a través de la “Notifications API”, utilizando los protocolos de “Amazon SQS” o “EventBridge”. La gran diferencia radica en la resiliencia: a diferencia de los “Webhooks” tradicionales, que dependen de un endpoint público del integrador siempre disponible, el modelo de Amazon permite que las notificaciones se encolen o se enruten dentro del entorno AWS, eliminando la pérdida de datos por inestabilidades externas. En el catálogo, esta arquitectura “Event-Driven” se alimenta de tópicos específicos como “listings_item_status_change” y “any_offer_changed”, garantizando que el integrador sepa exactamente cuándo se han actualizado los esquemas de datos de una categoría, permitiendo una reacción automatizada a cambios de conformidad y atributos. Este enfoque consolida la consistencia eventual del sistema, garantizando que el catálogo de la tienda refleje violaciones de políticas o métricas de rendimiento en tiempo real, sin el costo computacional y la latencia del polling.

eBay consolida su arquitectura orientada a eventos a través de la “Notification API”, utilizando el protocolo “HTTPS Webhooks” bajo un riguroso modelo de gobernanza que exige validaciones de “Challenge-Response Checks” (CRC) y firmas criptográficas para garantizar la autenticidad del endpoint. Este módulo “empuja” notificaciones en tiempo real sobre el ciclo de vida completo del catálogo, incluyendo eventos críticos como la creación (“ItemListed”), el cierre de listados (“ItemClosed”), revisiones de contenido (“ItemRevised”) y cambios de precio o cantidad (“ItemPriceAndQuantityModified”). Esta sofisticación en el monitoreo de temas transforma la gestión de inventario en un flujo reactivo y seguro, donde la integridad del listado público se mantiene sin la latencia del “polling”, garantizando que cualquier modificación sistémica o expiración de anuncio se refleje instantáneamente en la base de datos del integrador.

Analizando desde la perspectiva de la resiliencia, un problema latente del modelo de “Webhooks” es la fragilidad por depender de la salud del endpoint de la integradora. Si la integradora se desconecta por algunos minutos durante la hora pico, puede ser bombardeada con miles de solicitudes a la vez tan pronto como regrese, causando una nueva caída, el fenómeno conocido como “Thundering Herd” (Efecto Manada). Para mitigar este problema, es fundamental utilizar el retroceso exponencial (“Exponential Backoff”), un algoritmo de gestión de errores que aumenta el tiempo de espera exponencialmente a cada nuevo intento, en lugar de reenviar solicitudes fallidas inmediatamente o en intervalos fijos. Para optimizar aún más, se recomienda el uso de “Jitter”, que consiste en un valor aleatorio añadido al “Exponential Backoff” para distribuir las solicitudes a lo largo del tiempo, garantizando que el sistema objetivo reciba una carga distribuida y tenga más posibilidades de procesar las llamadas con éxito. El cálculo del tiempo de espera (E) aplicando estos conceptos se realiza mediante la ecuación 1:

E = random(0, intervalo inicial × 2^n) (1)

donde E es el tiempo de espera; random: es un número aleatorio que el sistema elige entre 0 y el resultado del cálculo exponencial; intervalo_inicial: es el tiempo de espera definido para la primera falla; n: es el número del intento actual. La implementación de estas técnicas es vital para la estabilidad de sistemas distribuidos y para evitar fallas en cascada.

La autenticación en ecosistemas de APIs actúa como el mecanismo fundamental para establecer identidad y confianza, asegurando que solo entidades legítimas accedan a recursos específicos a través de credenciales. Esta capa no solo sirve como barrera de seguridad, sino también como recurso de control para la gobernanza del tráfico (Wiggins, 2017). Al identificar el origen de la llamada, ya sea una aplicación centralizada de un integrador o una instancia autorizada de la tienda, el servidor puede aplicar políticas de limitaciones (“rate limit”) personalizadas, vinculando la capacidad de consumo de datos al nivel de autorización y al modelo de confianza establecido (Warrier, 2019).

iFood utiliza el protocolo OAuth 2.0 con tokens Bearer, operando en dos modelos: centralizado y distribuido. El flujo centralizado es para aplicaciones privadas, donde los “access tokens” se proporcionan para simplificar la gestión, pero los límites de tasa se contabilizan por aplicación, lo que puede hacer que las grandes integradoras alcancen cuellos de botella rápidamente. El flujo distribuido, dirigido a aplicaciones públicas, requiere autorización explícita del comerciante y proporciona un “refresh token”, distribuyendo la carga por instancia de la tienda y permitiendo una escalabilidad superior. 99Food utiliza OAuth 2.0 con un enfoque en un flujo de autenticación de servidor a servidor, similar al modelo centralizado de iFood, donde las credenciales se vinculan directamente a la integradora. La gestión de los límites de tasa se aplica de forma centralizada por “App ID”, lo que impone un desafío crítico de arquitectura para la integradora, ya que el consumo excesivo de un solo cliente puede agotar la cuota global, afectando a todos los demás comerciantes.

Amazon utiliza OAuth 2.0 integrado con AWS IAM, lo que exige que cada vendedor autorice la aplicación a través del flujo “Login with Amazon” (LWA), acercándose al modelo distribuido. Amazon mitiga el riesgo de agotamiento de límites por aplicación al implementar el “Rate Limiting per Seller”, aislando las cuotas de solicitud (basadas en el algoritmo “Token Bucket”) para cada cuenta de vendedor conectada. Para una integradora, esta arquitectura es ventajosa, ya que la adición de nuevos clientes no impacta la performance ni la disponibilidad de los clientes existentes, eliminando la necesidad de gestionar múltiples aplicaciones para sortear restricciones de tráfico globales. eBay adopta OAuth 2.0 con una distinción clara entre “Application access tokens” (para datos públicos) y “User access tokens” (para operaciones del vendedor). Sus rate limits son predominantemente cuotas diarias fijas por aplicación. Aunque una aplicación tiene un límite global de llamadas por día, grandes integradoras pueden solicitar aumentos de cuota basados en contratos comerciales y en la certificación de la aplicación, permitiendo una planificación de volumen de datos a largo plazo.

En el escenario brasileño, iFood y 99Food aún no adoptan cobro directo para integrar sus APIs. La estrategia de iFood se enfoca en la reducción del costo operativo y en la estabilidad de la plataforma, viendo la API como herramienta de captación de pedidos y monetizando vía comisiones sobre las ventas. Hay un movimiento de “premiumización” indirecta a través del Portal del Desarrollador, donde recursos avanzados de soporte y homologación (sello Super Integrador) exigen un nivel de calidad y certificación técnica. 99Food sigue una lógica similar, operando sin modelo de cobro directo, concediendo acceso como parte del ecosistema para socios logísticos y de Point of Sale (POS). El costo es absorbido por la comisión del marketplace, pero esta gratuidad resulta en “rate limits” más rígidos y menos flexibles, sin un “Service Level Agreement” (SLA) atado a un pago directo.

Amazon implementó uno de los modelos más estructurados de monetización de API, con el objetivo de desincentivar integraciones ineficientes (como el “polling” excesivo) y gestionar una nueva fuente de ingresos. La estructura se basa en una tarifa de suscripción anual para desarrolladores, sumada a un modelo de tarificación mensual por tramos de uso (“metered billing”) y nivel de soporte. El sistema ofrece franquicias mensuales de peticiones GET (consulta de datos) a partir del plan de suscripción adquirido, mientras que las peticiones que alteran datos (POST, PUT, PATCH) permanecen exentas para incentivar la actualización del ecosistema (Amazon Selling Partner API, 2025). Este modelo obliga a las integradoras a migrar a arquitecturas basadas en eventos (“Webhooks”), donde Amazon notifica sobre cambios, en lugar de que la integradora pregunte repetidamente. Las principales diferencias de los planes de Amazon se demuestran en la Tabla 2.

Tabla 2. Modelo de monetización de la API de Selling Partner de Amazon

Características	Básico	Profesor	Avanzado	Más	Empresa
Tasa anual ($)	1.400	1.400	1.400	1.400	1.400
Tarifa mensual ($)	0	1.000	5.000	10.000	A convenir
Llamadas GET/mes	2.500.000	25.000.000	125.000.000	250.000.000	A convenir
Llamadas PUT/PATCH/POST	Sin límites	Sin límites	Sin límites	Sin límites	Sin límites
Acceso al equipo de Comercial	No	No	Sí	Sí	Sí
Acceso a APIs Beta	No	No	No	Sí	Sí
Acceso a eventos exclusivos	No	No	No	Sí	Sí
Arquitecto de soluciones dedicado	No	No	No	No	Sí

Fuente: (Amazon Selling Partner API, 2025)

La Tabla 2 detalla los diferentes niveles de servicio de Amazon, desde el plan Básico hasta el Enterprise, mostrando cómo varían la tarifa anual y mensual, el volumen de llamadas GET/mes y el acceso a recursos exclusivos (como equipo comercial, APIs Beta, eventos exclusivos y arquitecto de soluciones dedicado). Esta estructura de precios no solo genera ingresos, sino que también funciona como una herramienta de gobernanza, incentivando prácticas eficientes y desestimulando el “polling” excesivo, que consume recursos innecesariamente. La exención de cobro para operaciones de escritura (POST, PUT, PATCH) es un incentivo directo para que los socios mantengan sus datos actualizados y consistentes, contribuyendo a la salud general del ecosistema.

El modelo de eBay se basa en límites de compatibilidad y acuerdos comerciales. Por defecto, ofrece una generosa cuota gratuita de llamadas diarias que satisface a pequeños y medianos desarrolladores. Para grandes integradoras que necesiten superar estos límites, eBay utiliza un proceso de certificación de aplicaciones. Una vez certificada, la negociación de límites adicionales puede implicar costos o ser subsidiada por el volumen de ventas generado por la herramienta dentro del marketplace (“Gross Merchandise Volume” [GMV]). Es un enfoque de monetización indirecta, donde eBay permite el uso masivo de la API sin cobro directo por llamada, siempre que la herramienta demuestre que está impulsando el GMV de la plataforma. Esta estrategia alinea los intereses de eBay con el éxito de sus socios, incentivando el crecimiento del ecosistema. La posibilidad de negociar límites en función del rendimiento del socio ofrece flexibilidad y un camino hacia la escalabilidad, pero exige un seguimiento riguroso del valor generado.

La propuesta de modelo de monetización para marketplaces consiste en una estrategia híbrida que combina suscripción y pago por uso. Para estimular la adopción, habría una versión gratuita, limitada a la utilización de un merchant de prueba en un entorno de desarrollo. Para la integración en producción, la integradora pasaría por homologación, con cobro de buenas prácticas y registro de información de cobro. La suscripción sería un valor fijo, variado por plan, y la integradora seleccionaría el plan más adecuado. Adicionalmente, habría un costo variable por uso de los endpoints, con un valor unitario por llamada exitosa. Los endpoints de consulta (GET) tendrían un costo menor que los de escritura (PUT, PATCH y POST), debido al costo diferenciado de la operación en la nube. Una sugerencia, con valores ficticios, se representa en la Tabla 3.

Tabla 3. Propuesta de modelo de monetización

Características	Estudiante	Básico	Profesor	Empresa
Mensualidad ($)	Gratis	2.000	5.000	10.000
Límite de llamadas/mes	5.000	25.000.000	125.000.000	250.000.000
Costo ($) /llamada PUT/PATCH/POST	Gratis	0,001	0,0005	0,0005
Costo ($) /llamada GET	Gratis	0,0001	0,0001	0,0001
Acceso a APIs Beta	No	No	Sí	Sí
Acceso a eventos exclusivos	No	No	Sí	Sí
Soporte con retorno hasta 3 horas	No	No	No	Sí

Fuente: Resultados originales de la investigación

La Tabla 3 presenta una estructura de planes (Student, Basic, Pro, Enterprise) con mensualidades y límites de llamadas/mes diferenciados. El costo por llamada para operaciones GET y PUT/PATCH/POST también varía, incentivando la eficiencia. Los planes más avanzados ofrecen acceso a APIs Beta, eventos exclusivos y soporte prioritario. Es crucial que el marketplace evalúe estratégicamente el posicionamiento de la monetización de sus APIs, ya que, si bien puede generar un activo financiero importante, también puede reducir el interés de clientes e integradoras, perjudicando la penetración en el mercado y la competitividad. Se necesita una proyección financiera y estratégica exhaustiva antes de la toma de decisiones, posiblemente con una implementación escalonada de los cobros. Este trabajo asume un escenario ideal donde estos factores fueron analizados y se tomó la decisión de monetizar.

La propuesta arquitectónica se centra en soportar el funcionamiento de un marketplace, integrando las tecnologías discutidas para garantizar resiliencia y alto rendimiento. La estructura abarca tres grandes módulos fundamentales: “API Management”, “Events” y “Catalog”, como se detalla en la Figura 4.

Figura 4. Propuesta de arquitectura de catálogo, eventos y monetización de API pública de marketplace.

Fuente: Resultados originales de la investigación

El flujo operativo se inicia cuando un integrador realiza una llamada, siendo el primer punto de contacto el módulo de “API Management”. Este componente es responsable de gestionar y orquestar las capas externa e interna del marketplace, operando el control de registros de llamadas (“logs”) y la aplicación de “rate limit”. Además, provee servicios esenciales de “API Gateway”, Autenticación (“Authentication”) y Cobranza (“Billing”), dirigiendo las peticiones a los módulos subsecuentes. Dentro de esta capa, el “API Gateway” organiza los flujos involucrados y despacha las llamadas a los servicios internos, mientras que el servicio de Autenticación (“authentication-api”) utiliza el protocolo OAuth 2.0, estándar de mercado que asegura que el “app” del integrador posea los permisos necesarios para interactuar con el marketplace y el “merchant” solicitado. Este proceso es sustentado por una base de datos específica, el “DB register-merchant-app”, que almacena las relaciones entre integradores y módulos habilitados. Paralelamente, el servicio de Cobranza (“integration-billing”) contabiliza el consumo, segregando llamadas GET de las demás operaciones para aplicar tarifas distintas, almacenando tales métricas en el “DB billing-integration”. Esta estructura permite una evolución futura para cobros granulares por endpoints específicos o por llamadas por módulo, adaptándose a las necesidades del negocio. La modularidad y la separación de responsabilidades en este módulo garantizan que la gestión de acceso, seguridad y facturación sea robusta y escalable, permitiendo que el marketplace adapte sus estrategias de monetización sin impactar la funcionalidad central de la API.

Si la solicitud se dirige a los endpoints de eventos, la “API Gateway” la dirige al módulo de “Events”. La arquitectura propone tres operaciones principales para la gestión de “webhooks”: POST /webhooks/subscription (para registrar la URL de la integradora y suscribirse para recibir eventos), GET /webhooks/subscription (para consultar la URL registrada) y DELETE /webhooks/subscription (para eliminar la URL y retirar la suscripción). Dichas llamadas son procesadas por el servicio de Suscripción de eventos (“events-subscription”), que administra las solicitudes y efectúa las suscripciones al asociar la integradora o “merchant” a la ruta indicada, persistiendo los datos en el “DB subscription”.

Si la llamada es para cambios en el catálogo, el “API Gateway” dirige al módulo de Catálogo, en el servicio responsable de administrar los cambios provenientes de la API pública (“catalog-public-api”). El “catalog-public-api”, al igual que otros servicios internos (Fraude, Pedidos, “Backoffice”, Portales del marketplace), se conecta directamente al servicio “core” (“catalog-service”), que es responsable de recibir, procesar y propagar los cambios realizados en las entidades del catálogo en todo el marketplace, almacenando estos eventos de cambio en una base de datos (“DB catalog”). El “catalog-service” notifica los eventos de cambio a un tópico (“catalog-events”), como “Kafka”, que se pone a disposición para consultas de los equipos internos.

El tópico “catalog-events” es consumido por un servicio de Eventos (“events-dispatcher”) que realiza las notificaciones para las integradoras de cambios en el catálogo, abriendo conexiones HTTP y esperando la respuesta de la integradora. Un punto relevante para la optimización de rendimiento es que, antes de procesar en el “events-dispatcher”, se realiza un filtro (“webhook filter”) responsable de pasar solo alteraciones de catálogo para “merchants” integrados que tienen suscripción en el módulo de Eventos, consultando esta información en la base de datos “subscription” para realizar el filtro. Para garantizar resiliencia y gestión de fallos en el modelo “Webhooks” propuesto, se incluyó un servicio de reintentos (“retry-manager”) para calcular el tiempo antes de realizar un reintento y agendar el mensaje en caso de que el endpoint de la integradora falle. Si los reintentos llegan al máximo establecido, los mensajes se almacenan en una “Dead Letter Queue” (DLQ) para auditoría, garantizando que ningún evento se pierda. El “retry-manager” debe gestionar el reintento basado en los conceptos de “Exponential Backoff” con ruido aleatorio (“Jitter”), conforme la ecuación 1, para evitar el “Thundering Herd” y garantizar que el sistema objetivo reciba una carga distribuida, aumentando las chances de éxito en el procesamiento de las llamadas.

4. Conclusión

Se concluye que el objetivo se alcanzó, al analizar y comparar las arquitecturas de marketplaces, centrándose en los módulos de catálogo, autenticación, límites de acceso y eventos, e investigar cómo estos componentes técnicos se rentabilizan en el escenario actual. El estudio confirmó la transición de las APIs de meras interfaces técnicas a activos estratégicos, esenciales en la “API Economy”, y demostró que la elección de los modelos de monetización está intrínsecamente ligada al nicho de actuación y a la madurez de la plataforma. Mientras los marketplaces de “Quick Commerce” priorizan la penetración de mercado a través de modelos gratuitos, los tradicionales han establecido patrones de monetización basados en suscripciones y uso, incentivando la eficiencia. Arquitectónicamente, la investigación evidenció la superioridad de la Arquitectura Orientada a Eventos (EDA) con mecanismos “push”, como webhooks, sobre el “polling” para garantizar la consistencia y reducir el tráfico redundante, especialmente en módulos críticos como el de Catálogo. La propuesta de arquitectura y monetización híbrida presentada busca soportar un marketplace resiliente y de alto rendimiento, integrando gestión de API, eventos y catálogo.

Sin embargo, este trabajo tiene limitaciones importantes. El análisis comparativo se limitó a un número selecto de marketplaces, y la propuesta de modelo de monetización se desarrolló en un escenario idealizado, sin validación empírica de su viabilidad financiera o impacto en el mercado. La arquitectura conceptual propuesta, aunque robusta, no se implementó ni se probó en un entorno real. Para estudios futuros, se sugiere la validación empírica del modelo de monetización en diferentes contextos de mercado, la implementación práctica y la evaluación del rendimiento de la arquitectura propuesta, y la expansión del análisis comparativo para incluir una gama más amplia de marketplaces y tipos de APIs, profundizando la comprensión de los impactos estratégicos y financieros de la monetización de APIs en la construcción de ecosistemas digitales.

Referencias Bibliográficas

Amazon Selling Partner API. 2025. An Update on SP-API Fees. Disponível em: <https://developer.amazonservices.com/spp-announcement.>. Acesso em: 01 abril 2026.

Chugh, Ishaana. 2026. The Economics of Emerging Business Models: A Literature Review of Subscription, Freemium, and Platform Strategies. International Journal For Multidisciplinary Research 8 (1): 1-12.

Eaton, B.; Henningsson, S.; Hedman, J.; Schneider, M.; Johansen, B. 2024. API Product Quality: A Comprehensive Reflection Guide. Copenhagen Business School. 12.

Edi Labs. 2024. Produtização e Monetização de APIs: Transformando Ativos Digitais em Fontes de Receita. Disponível em: <https://www.edi-labs.com/wp/2024/05/27/produtizacao-e-monetizacao-de-apis-transformando-ativos-digitais-em-fontes-de-receita/>. Acesso em: 20 janeiro 2026.

Gebauer, H.; Saul, C. J.; Haldimann, M.; Gustafsson, A. 2017. Organizational capabilities for pay-per-use services in product-oriented companies. International Journal of Production Economics 192 (3): 157-168.

Gunturu, N. M. 2022. Enterprise API Transformation: Driving towards API Economy. International Journal of Computer Trends and Technology 70(6): 44-50.

Hohpe, G.; Woolf, B. 2003. Messaging Systems. p. 75-105. In: Hohpe, G.; Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, Boston, MA, EUA. 2003. Disponível em <https://arquitecturaibm.com › uploads > 2015/03>. Acesso em: 01 abril 2026.

Hsu, P.; Yen, H.R.; Hu, P.J.; Nguyen, T.K. 2025. Converting free users to paying customers in freemium services: a SaaS success model. Information Systems and e-Business Management 23 (4), 355–390.

Jacobson, Brail e Iyver, 2011 [Referência completa não encontrada no documento original]

Jacobson, D.; Brail, G.; Woods, D. 2012. APIs: A strategy guide. O’Reilly Media, Inc., Sebastopol, CA, United States of America.

Johnson Mary, B. 2025. Monetizing APIs and Building Platform Ecosystems: Advanced Strategies for API-First Business Models and Developer Engagement in the Enterprise. Disponível em: <https://www.researchgate.net/publication/390493119> . Acesso em: 15 setembro 2025.

Onipede, G.D. 2024. API Monetisation strategies for FinTech Startups: Balancing innovation with revenue generation. International Journal of Science and Research Archive 11(01): 2668-2681.

Prado, R. 2025. Estudo de rentabilidade em marketplaces: Amazon, Shopee e Magalu. Disponível em: <https://www.ecommercebrasil.com.br/artigos/estudo-de-rentabilidade-em-marketplaces-comparando-vendas-entre-mercado-livre-amazon-shopee-e-magalu>. Acesso em: 29 janeiro 2026.

Qwist Research. 2026. API Monetization in Banking: Models & Revenue Strategies. Disponível em: https://qwist.com/en/resources/wiki/api-monetization-in-banking/. Acesso em: 29 janeiro 2026.

Richardson, C. 2018. Interprocess Communication in a Microservice Architecture. p. 82-88. In: Richardson, C. Microservices Patterns: With examples in Java. Manning Publications. Shelter Island, NY, USA.

Solanke, A.; Liang, W. 2022. Monetizing APIs and Building Platform Ecosystems: Advanced Strategies for API-First Business Models and Developer Engagement in the Enterprise. Disponível em: <https://www.researchgate.net/publication/390172837>. Acesso em: 15 setembro 2025.

Treinta, F. T.; Farias Filho, J. R.; Sant’Anna, N.P.; Rabelo, L.M. 2013. Metodologia de pesquisa bibliográfica com a utilização de método multicritério de apoio à decisão. FapUNIFESP (SciELO) 24(3): 508-520.

Verma, R.; Khound, K.; Mishra, V. 2025. Subscription Economy and the Transformation of Ownership: A Review of Value Perceptions and Retention Strategies. Advances in Consumer Research. 2(5): 935–951.

Warrier, A. 2019. Enterprise Healthcare API Management: Authentication, Authorization, and Rate Limiting for Regulated Environments. Journal of Advances in Developmental Research 10(1): 1-9.

Wiggins, A. 2017. The Twelve-Factor App. Disponível em: <https://12factor.net/pt_br/> Acesso em: 7 abril 2026.

Artículo originado del Trabajo de Conclusión de Curso de la Especialización en Ingeniería de Software del MBA USP/Esalq

Para saber más sobre el curso, haga clic aquí y acceda a la plataforma MBX Academy