Sarah Carnevali Semtchuk; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202601442

Article prepared by the ResumeAI tool, an artificial intelligence solution developed by the Pecege Institute focused on synthesis and writing.

Summary

Application Programming Interfaces (APIs) have consolidated as strategic assets in marketplaces, transitioning from technical functions to pillars of external integration and revenue generation vectors. The objective of this work was to analyze and compare marketplace architectures, focusing on the catalog, authentication, access limits, and events modules, investigating how these technical components are monetized in the current scenario. The research adopted a qualitative, propositional, and descriptive approach, using a multiple case study that compared traditional marketplaces (Amazon and eBay) with quick commerce platforms (iFood and 99Food). A systematic literature review and documentary research on developer portals were conducted, analyzing monetization and architecture patterns. The results showed that APIs have become products, with monetization models varying significantly: while quick commerce platforms prioritized market penetration through free models, traditional marketplaces established charges based on subscriptions and usage. Architecturally, the operational efficiency and scalability of integrators depended on the migration to an Event-Driven Architecture (EDA), replacing repetitive queries (polling) with push notification mechanisms (webhooks). It was observed that the adoption of EDA, especially for the Catalog module, offered greater efficiency and consistency in integration. A hybrid monetization model (subscription and pay-per-use) and a conceptual architecture with API Management, Events, and Catalog modules were proposed. It was concluded that the combination of a resilient architecture and well-structured monetization models creates a positive cycle of revenue and innovation, justifying charges for added value and promoting more efficient and sustainable operations.

Keywords: Event-driven architecture; API Economy; API Management; Digital platforms; Webhooks.

1. Introduction

The digital era has been marked by the rise and consolidation of virtual sales platforms, known as marketplaces, which have transformed the dynamics of commerce and the interaction between companies and consumers. By centralizing various sales channels, these platforms facilitate usability and streamline operations, expanding reach and boosting sales (Jacobson and Woods, 2012). In this scenario of intense digitalization, Application Programming Interfaces (APIs) have emerged as crucial elements, transcending their initial function as mere technical tools to become strategic assets. They act as essential pillars for external integration and as fundamental vectors for revenue generation, driving the so-called “API Economy” (Gunturu, 2022). Adopting an “API-first” strategy allows companies to optimize internal processes, create scalable platforms, and broaden their technological reach, generating new income streams and enhancing customer experience (Johnson Mary, 2025). The relevance of APIs is underscored by the growth of e-commerce and the demand for connectivity, making them indispensable for competitiveness in today’s market.

The transition from a technical interface API to a marketable asset is encapsulated by the concept of “API-as-a-Product.” This approach redefines the API not just as a software component, but as a product with measurable business value, designed to solve specific user problems (Eaton et al., 2024). Unlike an internal API, an API as a product requires lifecycle management, a focus on quality, usability, and customer support (Jacobson et al., 2011). API monetization, in turn, is the practice of generating revenue by granting controlled access to business services and functionalities, representing the final stage of this “productization” (Edi Labs, 2024). There are four main API monetization strategies, according to Solanke and Liang (2022): the “Subscription-Based” model for continuous access (Chugh, 2026; Verma et al., 2025); “Pay-Per-Use” which charges proportionally to actual consumption (Gebauer et al., 2017); the “Freemium” model which offers basic free access to attract broad adoption (Hsu et al., 2025); and “Revenue-Sharing” which remunerates the API provider with a percentage of revenue generated by third parties (Prado, 2025; Qwist Research, 2026). The choice of model should balance innovation and financial viability (Onipede, 2024).

In parallel with the evolution of business models, architectural choices play a decisive role in the operational efficiency and scalability of marketplaces. Traditionally, many systems rely on the “polling” model, where clients periodically check the server for updates. This approach generates voluminous and redundant network traffic, increasing latency and resource consumption, which becomes unsustainable in high-demand ecosystems (Richardson, 2018). In contrast, Event-Driven Architecture (EDA) represents a significant advancement, replacing “polling” with “push” notification mechanisms, such as *webhooks*. As detailed by Hohpe and Woolf (2003), EDA is based on messaging patterns that allow the marketplace to send critical updates to integrated systems as soon as a relevant change occurs. This approach promotes decoupling between services, ensures eventual data consistency, and improves ecosystem responsiveness. Implementing *webhooks* in critical modules, such as the catalog, can optimize resource consumption and offer integrity, instead of requiring constant checks. This architectural efficiency enhances the partner experience and justifies monetization by added value and superior performance.

The growing complexity of marketplaces and the evolution of APIs for monetizable strategic assets demand an understanding of the architectural nuances and business models that underpin this transformation. The gap in literature and market practices, especially regarding the monetization of technical components and the adoption of event-driven architectures, justifies the present investigation. The objective of this work was to analyze and compare marketplace architectures, focusing on the catalog, authentication, access limits, and events modules, investigating how these technical components are monetized in the current scenario.

2. Material and Methods

The present investigation was outlined under a qualitative approach, seeking to deepen the understanding of the phenomena studied through the analysis of non-numeric data and the interpretation of specific contexts. It was characterized as a purposeful research, as its purpose was the elaboration of practical models for monetization and the architecture of Application Programming Interfaces (APIs), and descriptive, by detailing the characteristics of marketplaces and their APIs. A multiple case study was adopted as the central method, allowing for a robust comparative analysis.

The study’s context focused on the analysis of digital sales platforms, known as marketplaces, and the evolution of Application Programming Interfaces (APIs) as strategic assets. The unit of analysis consisted of the architectures and API monetization models implemented by these platforms, focusing on specific modules such as catalog, authentication, access limits, and events. The research was conducted considering the current scenario of e-commerce digitalization, covering information available up to the year 2026, according to the work’s completion date.

The study sample was intentionally divided into two distinct groups to allow for an in-depth comparative analysis. The first group consisted of traditional “marketplaces” that already had monetized APIs, selected for their global relevance and for presenting consolidated business models and architecture. Platforms such as Amazon and eBay were included in this group, recognized for their developer ecosystems and the clarity of their API monetization and integration standards.

The second group of the sample comprised “marketplaces” from the “Quick Commerce” segment, characterized by ultra-fast delivery and convenience. The selection of these platforms aimed to investigate the monetization potential of their APIs, which, at the time of the research, were not directly monetized, and to identify architectural opportunities. iFood and 99Food were analyzed, both with a strong presence in the Brazilian scenario, whose public API documentation allowed for the evaluation of their structures and the identification of value gaps.

Data collection began with a systematic literature review, focused on fundamental concepts for the research. Topics such as “API-as-a-Product”, which addresses APIs as a product with business value, the “API Economy”, which describes the commercial ecosystem driven by APIs, and various monetization models, including subscription, pay-per-use, freemium, and revenue sharing, were explored. Data were extracted from specialized literature, conference papers, and open data repositories, following the methodology of Treinta et al. (2013).

In parallel with the literature review, a comprehensive documentary research was conducted on the selected platforms. This stage involved the analysis of public material made available by the companies, such as their developer portals, official API documentation, and terms of service. The objective was to obtain detailed information about the practical implementation of the APIs and their respective business models, complementing the theoretical foundation with real-world data.

During the documentary research, specific information was collected about the structure of the endpoints and the resources offered by the APIs of each marketplace. The presence and implementation of event-oriented architectures, such as the use of webhooks, were evaluated, in contrast to repetitive query models. Additionally, the pricing models and available integration plans were raised, seeking to understand the monetization strategies and access conditions for developers and partners.

The research execution steps were organized sequentially and complementarily. Initially, a systematic literature review was conducted to establish the theoretical and conceptual framework. Subsequently, and simultaneously at times, documentary research was carried out, which allowed for the collection of empirical data directly from the primary sources of the analyzed companies. This combined approach ensured a solid foundation of theoretical and practical knowledge for subsequent analysis.

After collection, the data were subjected to a comparative content analysis, a technique that allowed the identification and contrast of relevant patterns and characteristics among the different marketplaces. The main focus of the analysis was to map the monetization strategies and API architectures adopted, seeking to understand the similarities and differences between the groups of traditional marketplaces and “Quick Commerce” marketplaces. This methodology enabled the identification of trends and particularities in each segment.

Specifically in monetization analysis, crucial variables that determine the value and cost of APIs were compared. Pricing models, allowed usage volume, and limited resources, such as request limits and the amount of data accessible through the APIs, were examined. This detailed comparison allowed for the identification of how each marketplace structures its value proposition and the conditions for accessing and using its interfaces, revealing revenue generation approaches.

The architectural analysis focused on the value proposition of the Catalog, Authentication, Rate Limits, and Events modules. The implementation of “pooling” versus “push” mechanisms for webhooks for event communication was investigated, evaluating the efficiency and resilience of each approach. The objective was to identify the existing value “gaps” in current architectures and the monetization opportunities that could arise from optimizing these technical components in the two groups of marketplaces studied.

Based on the analyses carried out, a proposal for a monetization model and architecture was developed for marketplaces seeking to monetize their APIs. A hybrid monetization model was suggested, combining different charging strategies, justified by the added value and performance gains provided by the adoption of event-driven architectures. Additionally, a conceptual architecture for the implementation of webhooks was outlined, detailing the technical implications necessary for the efficient integration of partners into the platform’s ecosystem.

3. Results and Discussion

The evolution of Application Programming Interfaces (APIs) from mere technical tools to strategic business assets is a central phenomenon in the contemporary digital economy, reflecting a profound transformation in how companies operate and generate value. This movement, termed the “API Economy” by Gunturu (2022), describes a vibrant commercial ecosystem where organizations expose their digital assets, such as data and functionalities, to partners and third parties, creating new value streams and driving innovation. The transition from a purely technical view to a strategic “API-as-a-Product” approach is crucial for companies not only to survive but to thrive in this dynamic landscape.

The concept of “API-as-a-Product”, as articulated by Eaton et al. (2024), implies that an API should be designed to solve a specific user problem, whether that user is a developer or a business, possessing its own lifecycle, a well-defined market strategy, and measurable value. Unlike an internal API, which can be seen as a byproduct of a larger system, an external API, when treated as a product, requires the same management rigor as commercial software, such as “Software as a Service” (SaaS). This means an intense focus on quality, usability, customer support, and fundamentally, the developer experience, as emphasized by Jacobson, Brail, and Iyver (2011). Excellent documentation, ease of integration, and high reliability are pillars for the API’s attractiveness and adoption, regardless of the underlying technical complexity. Monetization, in this context, is not just a financial decision but the final stage of this “productization”, where internal digital assets are converted into sustainable revenue streams, overcoming pricing complexities (Edi Labs, 2024). This organizational maturity in API management allows for mitigating obsolescence risks and capturing real economic value in ecosystems.

Regarding API monetization models in marketplaces, the research identified four main strategies, according to Solanke and Liang (2022): subscription (“Subscription-Based”), pay-per-use (“Pay-Per-Use”), “freemium”, and revenue sharing (“Revenue-Sharing”). Each of these models has distinct characteristics and is best suited to different business contexts and service types. The subscription model, for example, is based on a recurring fee for continuous access to a product or service, establishing a lasting relationship between provider and customer (Chugh, 2026). Its advantages include lower initial cost and predictability, which reduces the barrier to entry for users. This model is particularly effective for products with frequent use and that receive constant updates and improvements, such as software, digital infrastructure, and platform access, as pointed out by Verma et al. (2025). The predictability of revenue for the provider and cost for the consumer makes it attractive for essential services and those with consistent value.

In contrast, the pay-per-use model (“Pay-Per-Use”) remunerates the provider based on the actual consumption of the service, aligning the charge with the effective utility. This pattern is ideal for high-volume services, such as payment gateways, and allows for greater customization and scalability for the client, who pays only for what they use. However, its implementation requires extremely robust and accurate real-time monitoring systems to control demand flow and ensure the viability of the model, as highlighted by Gebauer et al. (2017). The technical and architectural complexity of tracking and billing granular usage can be a significant challenge, but the benefits in terms of flexibility and alignment with the delivered value justify the investment.

The “freemium” model represents a hybrid strategy, offering a layer of essential services for free to attract a broad user base, while advanced functionalities, premium features, or unrestricted access are commercialized (Chugh, 2026). In platform environments and digital ecosystems, this approach is powerful for mitigating entry barriers and accelerating “network effects”, maximizing the platform’s liquidity and perceived value. Monetization occurs through the strategic conversion of engaged users who demand greater productive capacity or specialized support (Hsu et al., 2025). This model is particularly relevant for marketplaces seeking to rapidly expand their partner base before introducing direct charges.

Finally, the Revenue-Sharing model is widely used on large-scale platforms, such as Mercado Livre, where the API provider receives a percentage of the revenue generated by third parties using the API to enable profitable transactions or services (Prado, 2025). API integration allows these platforms to capture the value of each transaction in real-time, and the model scales with the seller’s success, aligning the financial interests of all participants. In addition to commissions, modern marketplaces use APIs to offer value-added services, such as credit and receivables factoring, transforming operational costs into new revenue streams and the platform into a financial infrastructure provider (Qwist Research, 2026). This approach allows for the implementation of pay-per-use models or subscription tiers for features that increase conversion, such as intelligent shipping calculation or integration with ERP systems. The complexity of monetization models deepens when the marketplace acts as an environment where partners can sell their own software via SaaS, monetizing not only API access but also the infrastructure and ecosystem it offers, as exemplified by the Amazon Selling Partner API (2025).

The analysis of the Catalog module revealed significant differences between “Quick Commerce” marketplaces and traditional ones, reflecting their distinct business logics and architectural priorities. In “Quick Commerce” platforms, such as iFood and 99Food, data volatility and menu hierarchy granularity are high, given the priority of the hyperlocal model and immediate availability. The root entity in these systems is the store (“merchant”), making the offering unique and customizable. Technically, an item from one unit does not share identifiers or attributes with that of another, even if they are similar products, which requires very low latency systems to ensure real-time consistency between physical stock and the digital storefront.

At iFood, the catalog architecture, as illustrated in Figure 1, follows the REST pattern with JSON payloads, structured in three levels: Categories, Items, and Add-on Groups (Modifiers). The Product entity acts as the master record for essential information, such as name, description, barcode (EAN), and images. The Product is sale-agnostic until it is instantiated as an Item (linked to a Category for display) or as an Add-on (associated with an Add-on Group for customization). While the Product holds intrinsic properties, the Item and Add-on carry transactional properties, such as price and availability, which can vary by channel. This structure, although flexible for customizing local menus, poses challenges in data management and scalability for integrators operating with multiple merchants, as granularity and volatility require frequent and precise updates to maintain consistency between physical and digital inventory. The need to manage price and availability variations at the item and add-on level, per channel, increases the complexity of the integration logic for partners.

Figure 1. Diagram of the entities that compose the iFood catalog architecture

Source: Original research results

99Food, in turn, adopts a supply-driven architecture, but without the Product entity, reusing the Item entity. The role of the object is defined by the “is_sold_separately” attribute: if “true”, the Item is offered individually; if “false”, it acts only as a modifier within a group (“Modifier Group”). A critical point of this format is that status changes are global, making it impossible to deactivate an item in direct sales and keep it active as a modifier. This structure, outlined in Figure 2, simplifies modeling by reducing the number of entities, but introduces rigidity in availability management that can be problematic for merchants who desire flexibility in product offerings. For example, an item that is a modifier (like a sauce) cannot be sold separately if its status is globally “false”, limiting the merchant’s sales strategies.

Figure 2. Diagram of the entities that compose the 99Food catalog architecture

Source: Original research results

Regarding the endpoints, iFood offers a wider range of granular CRUD operations (Catalog, Category, Item, Complement), which, although requiring greater control from integrators, are more performant. To simplify, the PUT /items endpoint allows for an “atomic write” strategy, updating the entire dependency tree in a single request, which reduces network calls (“round-trips”), but can generate latency spikes in extensive catalogs due to complex schema validation. 99Food, on the other hand, adopts a minimalist, state-synchronization-oriented approach, with data recovery via GET endpoints for reading the complete catalog and writing via dense payloads in “Bulk Update”. This simplifies the integrator’s logic, eliminating the management of dependency creation order, but, as with iFood, this centralization generates processing overhead and increased latency when only simple attributes, such as price, need to be changed. Table 7, although not included in the final selection, details the equivalence between the endpoints of the two platforms, highlighting the different approaches to catalog management.

Unlike them, traditional marketplaces, such as Amazon and eBay, operate under a logic of global indexing and scalable search. The central entity is the industrialized Product, using global codes like “Stock Keeping Unit” (SKU), in an N:N relationship (one item for multiple sellers). The focus lies on technical standardization and navigability in deep taxonomies, allowing precise filters and price comparison between different offers of the same product. This approach is fundamental for large-scale ecosystems, where consistency and standardization are more valued than hyper-local customization.

Catalog management on Amazon is divided into four modules: “Catalog Items API”, “Product Type Definition API”, and “Listing Items API”. The “Catalog Items API” allows discovery in the global repository via EAN or name, returning the “Amazon Standard Identification Number” (ASIN), essential for the “matching” process, where the seller links their offer to an already cataloged product. The “Product Type Definitions API” dynamically provides the JSON schema with validation requirements for each category, avoiding rigid schemas for millions of item types and reducing synchronous processing errors. Finally, the “Listing Items API” manages the seller’s offers (“Seller”), allowing granular manipulation via PUT (full update) or PATCH (partial update), resolving concurrency issues and controlling the offer lifecycle. Figure 3 illustrates the connection between Amazon entities, where the combination of brand, product, and variations results in the “Child ASIN”, which, integrated with the seller’s inventory, becomes a “Listing Item” with commercial offer conditions. This complex yet robust architecture ensures data integrity in a global and highly scalable ecosystem. The ability to dynamically define data schemas is a significant advantage, as it allows the platform to adapt to new product categories without requiring major refactoring, a common challenge in legacy systems.

Figure 3. Diagram of the entities that compose Amazon’s catalog architecture

Source: Original research results

eBay, with its “Inventory API”, adopts a hybrid premise, separating inventory (“Inventory Item”) from commercial publication (“Listing”). While on Amazon the offer is intrinsic to the ASIN, on eBay the developer creates their own Item per store and links it to an “eBay Product Identifier” (ePID) for relevance, aiming for user organization, but maintaining the need to register individual metadata per store. The Item stores technical data, seller SKU, inventory, and price, while the “Listing” holds business rules such as shipping policies and offer display. eBay allows heterogeneous listings via “Aspects” (descriptive metadata), and management requires a three-step workflow: item creation, offer creation, and publication, providing granular state control. Figure 9, although not included in the final selection, outlines this relationship, showing how eBay balances flexibility for sellers with the need for buyer organization.

In summary, while “Quick Commerce” focuses on state synchronization and dynamic modifiers to address local operation volatility, the traditional marketplace prioritizes metadata governance and global search scalability through unique identifiers (ASIN/ePID). This catalog structuring defines the rules of “what” is being sold, but the operational efficiency of the integration depends on “how” the endpoints are structured and how these data changes are communicated between external and internal platforms.

The Events module is the reactive and asynchronous communication layer of the APIs, essential for the scalability of high-performance marketplaces, replacing the repetitive query model (“polling”) with an Event-Driven Architecture (EDA), as detailed by Hohpe and Woolf (2003). This approach, based on messaging patterns, allows the marketplace to push critical updates to integrated systems whenever a relevant change occurs. This module ensures eventual consistency between distributed systems and promotes decoupling between services, ensuring the ecosystem’s responsiveness efficiently (Richardson, 2018).

The analysis of this module reveals that the fundamental difference between “Quick Commerce” and traditional marketplaces lies not only in the protocol but in the delivery model and the criticality of latency. “Quick Commerce” demands an almost instantaneous response for synchronization, with the architecture predominantly based on “HTTP Webhooks”. In this model, the marketplace acts as a client making POST requests to a pre-defined endpoint by the integrator, requiring it to be highly available. Low latency is crucial for the user experience, where product and price availability must be updated in milliseconds. However, event persistence is generally ephemeral, depending on retries, which can lead to data loss in case of prolonged failure of the integrator’s endpoint.

On the other hand, the Traditional marketplace prioritizes durability and ordering of events on a large scale. Due to the massive volume and the possibility of higher latency, platforms like Amazon can offer more robust options than simple “Webhooks”, integrating directly with cloud services like “AWS SQS” or “Amazon EventBridge”. In this model, the integrator does not need to expose a public endpoint and guarantee its high availability, only consume messages from a queue that is stored with greater persistence and without risk of event loss in case of unavailability. Table 1 compares the characteristics of these different notification models.

Table 1. Comparison of the characteristics of different types of notification systems

Characteristic	iFood, 99Food and eBay	Amazon
Protocol	“Webhooks (HTTP/HTTPS)”	“SQS”, “EventBridge”
Data flow	“Push” (The marketplace sends)	“Pull”/”Reactive” (The system consumes from the queue)
Latency	Milliseconds to a few seconds	Seconds to minutes (tolerable)
Persistence of events	Generally ephemeral (depends on retries)	High availability (messages persisted in queues)
Infrastructure complexity	Low (requires only a web server)	High/Medium (displays cloud infra or queue polling)

Source: Original research results

Table 1 clearly illustrates the trade-offs: while Webhooks (HTTP/HTTPS) offer millisecond latency, their persistence is ephemeral. In contrast, cloud queue-based systems (SQS, EventBridge) can have latency from seconds to minutes, but guarantee high event persistence. The infrastructure complexity for Webhooks is low (requires only a web server), while for cloud systems it can be medium/high, depending on the infrastructure and the queue “polling” model. This comparison is vital for the architectural choice, which should align with business needs and resilience requirements.

At iFood, maintaining data consistency between the marketplace and external systems like ERPs reveals a dependency on the “polling” model in most modules, with the exception of the Orders module which has integration with “HTTPS Webhooks”. This “data pull” architecture generates voluminous and redundant traffic, highlighting a technological gap for the transition towards an event-driven “API-First” model. The implementation of catalog “Webhooks” would transform this dynamic, replacing constant checking with reactive alteration notifications, optimizing resource consumption and offer integrity. 99Food, in contrast, presents a more capillary and “Webhook”-tied event structure, extending reactivity beyond the “Order” module to encompass the “Store”, Menu, and “Logistics” modules. This approach demonstrates a massive asynchronous state management structure, allowing the external system to react immediately to “Backoffice” processes that, in “polling” models, would require complex request orchestration.

In the Amazon ecosystem, the messaging strategy evolves towards native integration with cloud infrastructures through the “Notifications API”, utilizing “Amazon SQS” or “EventBridge” protocols. The main differentiator lies in resilience: unlike traditional “Webhooks”, which depend on a constantly available public endpoint of the integrator, Amazon’s model allows notifications to be queued or routed within the AWS environment, eliminating data loss due to external instabilities. In the catalog, this “Event-Driven” architecture is fed by specific topics such as “listings_item_status_change” and “any_offer_changed”, ensuring that the integrator knows exactly when a category’s data schemas have been updated, allowing for automated reaction to compliance and attribute changes. This approach consolidates the system’s eventual consistency, ensuring that the store catalog reflects policy violations or performance metrics in real-time, without the computational cost and latency of polling.

eBay consolidates its event-driven architecture through the “Notification API”, utilizing the “HTTPS Webhooks” protocol under a strict governance model that requires “Challenge-Response Checks” (CRC) validations and cryptographic signatures to ensure endpoint authenticity. This module “pushes” real-time notifications about the complete catalog lifecycle, including critical events such as creation (“ItemListed”), listing closure (“ItemClosed”), content revisions (“ItemRevised”), and price or quantity changes (“ItemPriceAndQuantityModified”). This sophistication in topic monitoring transforms inventory management into a reactive and secure flow, where the integrity of the public listing is maintained without the latency of “polling”, ensuring that any systemic modification or ad expiration is instantly reflected in the integrator’s database.

Analyzing from a resilience perspective, a latent problem with the “Webhooks” model is its fragility due to its dependence on the integrator’s endpoint health. If the integrator goes offline for a few minutes during peak hours, it can be bombarded with thousands of requests at once when it comes back online, causing another outage, a phenomenon known as “Thundering Herd”. To mitigate this problem, it is essential to use “Exponential Backoff”, an error management algorithm that exponentially increases the waiting time with each new attempt, instead of resending failed requests immediately or at fixed intervals. To further optimize, the use of “Jitter” is recommended, which consists of a random value added to the “Exponential Backoff” to distribute requests over time, ensuring that the target system receives a distributed load and has a better chance of processing calls successfully. The calculation of the waiting time (E) applying these concepts is performed by equation 1:

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

where E is the waiting time; random is a random number that the system chooses between 0 and the result of the exponential calculation; interval_inicial is the waiting time defined for the first failure; n is the current attempt number. The implementation of these techniques is vital for the stability of distributed systems and to avoid cascading failures.

Authentication in API ecosystems acts as the fundamental mechanism for establishing identity and trust, ensuring that only legitimate entities access specific resources through credentials. This layer not only serves as a security barrier but also as a control feature for traffic governance (Wiggins, 2017). By identifying the origin of the call, whether it’s a centralized application from an integrator or an authorized store instance, the server can apply customized rate limit policies, linking data consumption capacity to the authorization level and the established trust model (Warrier, 2019).

iFood uses the OAuth 2.0 protocol with Bearer tokens, operating in two models: centralized and distributed. The centralized flow is for private applications, where “access tokens” are provided to simplify management, but rate limits are accounted for per application, which can lead large integrators to quickly reach bottlenecks. The distributed flow, aimed at public applications, requires explicit merchant authorization and provides a “refresh token”, distributing the load per store instance and allowing for superior scalability. 99Food uses OAuth 2.0 with a focus on a server-to-server authentication flow, similar to iFood’s centralized model, where credentials are directly linked to the integrator. Rate limit management is applied centrally per “App ID”, which imposes a critical architectural challenge for the integrator, as excessive consumption by a single client can deplete the global quota, affecting all other merchants.

Amazon uses OAuth 2.0 integrated with AWS IAM, requiring each seller to authorize the application through the “Login with Amazon” (LWA) flow, approaching the distributed model. Amazon mitigates the risk of application-level limit exhaustion by implementing “Rate Limiting per Seller”, isolating request quotas (based on the “Token Bucket” algorithm) for each connected seller account. For an integrator, this architecture is advantageous, as adding new clients does not impact the performance or availability of existing clients, eliminating the need to manage multiple applications to circumvent global traffic restrictions. eBay adopts OAuth 2.0 with a clear distinction between “Application access tokens” (for public data) and “User access tokens” (for seller operations). Its rate limits are predominantly fixed daily quotas per application. Although an application has a global call limit per day, large integrators can request quota increases based on commercial agreements and application certification, allowing for long-term data volume planning.

In the Brazilian scenario, iFood and 99Food do not yet adopt direct charging to integrate their APIs. iFood’s strategy focuses on reducing operational costs and platform stability, viewing the API as a tool for capturing orders and monetizing through sales commissions. There is a movement of indirect “premiumization” through the Developer Portal, where advanced support and homologation features (Super Integrator seal) require a level of quality and technical certification. 99Food follows a similar logic, operating without a direct charging model, granting access as part of the ecosystem for logistics and Point of Sale (POS) partners. The cost is absorbed by the marketplace commission, but this gratuity results in stricter and less flexible “rate limits”, without a “Service Level Agreement” (SLA) tied to direct payment.

Amazon implemented one of the most structured API monetization models, aiming to discourage inefficient integrations (such as excessive “polling”) and manage a new revenue stream. The structure is based on an annual subscription fee for developers, added to a monthly usage-based pricing model (“metered billing”) and support level. The system offers monthly quotas of GET requests (data queries) based on the acquired subscription plan, while requests that alter data (POST, PUT, PATCH) remain free to encourage ecosystem updates (Amazon Selling Partner API, 2025). This model forces integrators to migrate to event-based architectures (“Webhooks”), where Amazon notifies about changes, instead of the integrator repeatedly asking. The main differences between Amazon’s plans are shown in Table 2.

Table 2. Amazon Selling Partner API monetization model

Resources	Fundamental	Program	Higher-level	Advantage	Company
Annual rate ($)	1.400	1.400	1.400	1.400	1.400
Monthly rate ($)	0	1.000	5.000	10.000	To be agreed
GET/month Calls	2.500.000	25.000.000	125.000.000	250.000.000	To be agreed
PUT/PATCH/POST Calls	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited
Access to the Commercial team	No	No	Yes	Yes	Yes
Beta APIs Access	No	No	No	Yes	Yes
Access to exclusive events	No	No	No	Yes	Yes
Dedicated solutions architect	No	No	No	No	Yes

Source: (Amazon Selling Partner API, 2025)

Table 2 details Amazon’s different service levels, from the Basic to the Enterprise plan, showing how the annual and monthly fee, the volume of GET calls/month, and access to exclusive resources (such as sales team, Beta APIs, exclusive events, and dedicated solutions architect) vary. This pricing structure not only generates revenue but also functions as a governance tool, encouraging efficient practices and discouraging excessive “polling”, which consumes resources unnecessarily. The exemption from charges for write operations (POST, PUT, PATCH) is a direct incentive for partners to keep their data updated and consistent, contributing to the overall health of the ecosystem.

eBay’s model is based on compatibility limits and commercial agreements. By default, it offers a generous free quota of daily calls that serves small and medium developers. For large integrators who need to exceed these limits, eBay uses an application certification process. Once certified, the negotiation of additional limits may involve costs or be subsidized by the sales volume generated by the tool within the marketplace (“Gross Merchandise Volume” [GMV]). It is an indirect monetization approach, where eBay allows massive API usage without direct charge per call, as long as the tool proves it is driving the platform’s GMV. This strategy aligns eBay’s interests with the success of its partners, encouraging ecosystem growth. The possibility of negotiating limits based on partner performance offers flexibility and a path to scalability, but requires rigorous monitoring of the value generated.

The proposed monetization model for marketplaces consists of a hybrid strategy that combines subscription and pay-per-use. To encourage adoption, there would be a free version, limited to the use of a test merchant in a development environment. For production integration, the integrator would undergo homologation, with charges for best practices and registration of billing information. The subscription would be a fixed amount, varying by plan, and the integrator would select the most suitable plan. Additionally, there would be a variable cost per use of the endpoints, with a unit cost per successful call. Query endpoints (GET) would have a lower cost than write endpoints (PUT, PATCH, and POST), due to the differentiated cost of cloud operations. A suggestion, with fictitious values, is represented in Table 3.

Table 3. Proposed monetization model

Resources	Learner	Fundamental	Program	Company
Monthly fee ($)	Free	2.000	5.000	10.000
Limit calls/month	5.000	25.000.000	125.000.000	250.000.000
Cost ($) /call PUT/PATCH/POST	Free	0,001	0,0005	0,0005
Cost ($) /GET call	Free	0,0001	0,0001	0,0001
Beta APIs Access	No	No	Yes	Yes
Access to exclusive events	No	No	Yes	Yes
Support with return up to 3 hours	No	No	No	Yes

Source: Original research results

Table 3 presents a structure of plans (Student, Basic, Pro, Enterprise) with differentiated monthly fees and call limits/month. The cost per call for GET and PUT/PATCH/POST operations also varies, encouraging efficiency. More advanced plans offer access to Beta APIs, exclusive events, and priority support. It is crucial that the marketplace strategically evaluates the positioning of its API monetization, as, although it can generate an important financial asset, it can also reduce the interest of clients and integrators, harming market penetration and competitiveness. An exhaustive financial and strategic projection is necessary before decision-making, possibly with a phased implementation of charges. This work assumes an ideal scenario where these factors have been analyzed and the decision for monetization has been made.

The architectural proposal’s central focus is to support the functioning of a marketplace, integrating the discussed technologies to ensure resilience and high performance. The structure encompasses three major fundamental modules: “API Management”, “Events”, and “Catalog”, as detailed in Figure 4.

Figure 4. Proposed architecture for marketplace public API catalog, events, and monetization.

Source: Original research results

The operational flow begins when an integrator makes a call, with the “API Management” module being the first point of contact. This component is responsible for managing and orchestrating the external and internal layers of the marketplace, operating call logging (“logs”) and applying “rate limits”. Additionally, it provides essential services for “API Gateway”, Authentication (“Authentication”), and Billing (“Billing”), directing requests to subsequent modules. Within this layer, the “API Gateway” organizes the involved flows and dispatches calls to internal services, while the Authentication service (“authentication-api”) uses the OAuth 2.0 protocol, a market standard that ensures the integrator’s “app” has the necessary permissions to interact with the marketplace and the requested “merchant”. This process is supported by a specific database, “DB register-merchant-app”, which stores the relationships between integrators and enabled modules. In parallel, the Billing service (“integration-billing”) accounts for consumption, segregating GET calls from other operations to apply distinct tariffs, storing these metrics in “DB billing-integration”. This structure allows for future evolution towards granular billing per specific endpoints or per module calls, adapting to business needs. The modularity and separation of responsibilities in this module ensure that access management, security, and billing are robust and scalable, allowing the marketplace to adapt its monetization strategies without impacting the core API functionality.

If the request is destined for the event endpoints, the “API Gateway” directs it to the “Events” module. The architecture proposes three main operations for “webhooks” management: POST /webhooks/subscription (to register the integrator’s URL and subscribe to receive events), GET /webhooks/subscription (to query the registered URL), and DELETE /webhooks/subscription (to delete the URL and unsubscribe). Such calls are processed by the event subscription service (“events-subscription”), which manages the requests and makes the subscriptions effective by associating the integrator or “merchant” with the indicated route, persisting the data in the “DB subscription”.

If the call is for catalog changes, the “API Gateway” directs to the Catalog module, in the service responsible for managing changes coming from the public API (“catalog-public-api”). The “catalog-public-api”, as well as other internal services (Fraud, Orders, “Backoffice”, Marketplace Portals), connects directly to the “core” service (“catalog-service”), which is responsible for receiving, processing, and propagating changes made to catalog entities throughout the marketplace, storing these change events in a database (“DB catalog”). The “catalog-service” notifies change events to a topic (“catalog-events”), such as “Kafka”, which is made available for internal teams’ queries.

The “catalog-events” topic is consumed by an Events service (“events-dispatcher”) that performs notifications for catalog change integrators, opening HTTP connections and waiting for the integrator’s response. A relevant point for performance optimization is that, before processing in the “events-dispatcher”, a filter (“webhook filter”) is performed, responsible for passing only catalog changes to integrated “merchants” that are subscribed to the Events module, consulting this information in the “subscription” database to perform the filter. To ensure resilience and fault management in the proposed “Webhooks” model, a retry service (“retry-manager”) was included to calculate the time before performing a retry and schedule the message if the integrator’s endpoint fails. If retries reach the established maximum, messages are stored in a “Dead Letter Queue” (DLQ) for auditing, ensuring that no event is lost. The “retry-manager” must manage retries based on the concepts of “Exponential Backoff” with random noise (“Jitter”), according to equation 1, to avoid “Thundering Herd” and ensure that the target system receives a distributed load, increasing the chances of successful call processing.

4. Conclusion

It is concluded that the objective was achieved by analyzing and comparing marketplace architectures, focusing on catalog, authentication, access limits, and events modules, and investigating how these technical components are monetized in the current scenario. The study confirmed the transition of APIs from mere technical interfaces to strategic assets, essential in the “API Economy”, and demonstrated that the choice of monetization models is intrinsically linked to the niche of operation and platform maturity. While “Quick Commerce” marketplaces prioritize market penetration through free models, traditional ones have established monetization standards based on subscriptions and usage, encouraging efficiency. Architecturally, the research highlighted the superiority of Event-Driven Architecture (EDA) with “push” mechanisms, such as webhooks, over “polling” to ensure consistency and reduce redundant traffic, especially in critical modules like the Catalog. The proposed hybrid architecture and monetization aims to support a resilient and high-performance marketplace, integrating API, event, and catalog management.

However, this work has important limitations. The comparative analysis was restricted to a select number of marketplaces, and the proposed monetization model was developed in an idealized scenario, without empirical validation of its financial viability or market impact. The proposed conceptual architecture, although robust, was not implemented or tested in a real environment. For future studies, it is suggested to empirically validate the monetization model in different market contexts, the practical implementation and performance evaluation of the proposed architecture, and the expansion of the comparative analysis to include a broader range of marketplaces and API types, deepening the understanding of the strategic and financial impacts of API monetization in the construction of digital ecosystems.

Bibliographic References

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.

Article originating from the Final Course Work of the Specialization in Software Engineering of the MBA USP/Esalq

To learn more about the course, click here and access the MBX Academy platform