--- title: What the Toll Management Project Taught Us About Negotiating API Access as a New Entrant description: How to negotiate API access with toll providers as a new entrant, from building credibility with mid-tier operators to winning over incumbents. image: https://weareaffective.com/hubfs/learning-centre-images/what-the-toll-management-project-taught-us-about-negotiating-api-access-as-a-new-entrant.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-the-toll-management-project-taught-us-about-negotiating-api-access-as-a-new#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What the Toll Management Project Taught Us About Negotiating API Access as a New Entrant Table of Contents Toll management sounds like a solved problem. Roads exist, charges apply, technology handles the rest. When we started working on a toll management platform, that was roughly the assumption we brought to the first conversation. What we found instead was a fragmented landscape of providers operating on entirely different rules, with no shared infrastructure, no consistent API, and no obvious route for a new entrant to plug in. > Getting API access from incumbents is less a technical hurdle and more a credibility negotiation. The lesson we had to learn, and then explain to our client, was that API access in regulated or incumbent-dominated markets is rarely a technical problem. The technology usually exists. The question is whether anyone with the keys will give them to you, and on what terms. What followed was a process of mapping the real landscape, understanding what established toll operators actually needed before they would engage, building a working product that did not depend on their cooperation, and then using that working product as the thing that eventually opened the door. This article covers what we did, what we found, and what the whole experience changed about how we [approach integration planning on any product](https://weareaffective.com/app-planning-strategy) that depends on third-party data access. ## Why API Access Is a Negotiation, Not a Technical Problem When clients come to us with a product that needs to pull data from an established platform or operator, the first instinct is to treat it as a development task. Find the API documentation, get credentials, connect. That works in markets where access is open by design. It does not work in markets where incumbent operators have no commercial incentive to help a new entrant succeed, and every operational reason to be cautious about who they share data with. Toll operators sit firmly in the second category. They hold customer vehicle data, transaction histories, and payment infrastructure built over years. Sharing that via an API requires trust in the party asking, legal agreement on liability, and operational confidence that the integration will not create problems for their own customers. A new product with no track record gives them nothing to assess any of those things on. So the conversation that needs to happen before any technical planning is not "what does their API support?" but "what would it take for them to trust us enough to have this conversation at all?" That reorientation matters because it changes where you spend your energy in the early stages. Chasing API documentation from a provider who has not agreed to work with you is wasted work. Building a product that demonstrates you are a serious operator is not. ## What We Found When We Mapped the Toll Provider Landscape On the toll management project, one of the first things we did was map the provider landscape properly. What we found was not encouraging from a direct integration standpoint. There was no coherent or consistent API across toll providers. Each provider operated on its own rules. Some accepted cash at point of use. Some were card only. Fee structures varied by vehicle axle count on some networks, while others used a flat rate regardless of vehicle type. The inconsistency was not just a technical complexity. It meant that even if individual providers had been willing to open API access, building a unified product on top of those integrations would have required constant maintenance as each provider changed its own systems. The fragmentation was structural, not an oversight that would eventually be fixed. This is the kind of thing that only becomes visible when you do the mapping work before committing to an architecture. We often find that [products are scoped assuming clean, consistent third-party data access](https://weareaffective.com/learning-centre/what-the-toll-management-project-taught-us-about-betting-a-product-on-an-api-tha), and the discovery that access is neither clean nor consistent arrives late, at a point where changing the approach is expensive. On this project, finding it early gave us room to recommend a different model entirely, rather than discovering the problem mid-build. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The Credibility Problem: Why Incumbents Say No to New Entrants There is a pattern we have seen across several projects where a product needed to negotiate access to an established operator's infrastructure. The incumbent's default position is caution, and that caution is rational. Letting a new product connect to your systems creates risk you cannot fully assess until something goes wrong. If the new product handles customer data poorly, the incumbent faces reputational and potentially legal exposure. If the integration breaks at a critical moment, the incumbent's own customers are affected. Against those risks, the benefit to the incumbent is limited. They are not launching the new product. They are not sharing in its revenue, at least not at the outset. A new entrant with no live customers represents an uncertain upside and a concrete downside. > An unproven product gives incumbents nothing to assess, and every reason to say no. On the toll management project, we made this case explicitly to our client. A brand-new, unproven product would struggle to negotiate API access with incumbents. The operators had no reason to extend trust to a platform with no live users and no operational history. The smarter path was to launch the product on a different model, build a demonstrable track record, and use that track record as the credibility that eventually opens the conversation. The client accepted this, and it shaped everything that followed. Before approaching an incumbent for API access, document your product's operational capacity: what your data handling policies are, how you manage customer relationships, and what your technical resilience looks like. Operators are evaluating whether you are a safe partner. ## Building Without API Access: The Preloaded Credit Model The solution we arrived at on the toll management project was to build the product in a way that did not depend on real-time integration with toll operators at all. We set up corporate accounts with each toll provider directly, registered customer vehicle plates to those accounts, and had customers preload credit onto the platform. When a toll was incurred, funds were deducted from the customer's preloaded balance against the platform's account with the relevant provider. This meant the product could launch without depending on any cooperation from individual toll operators at the API level. The platform held the corporate relationship with each provider. Customers interacted only with the platform. The absence of a direct integration became invisible to the end user. The model also had a financial elegance to it. Because customers preloaded credit, the platform held funds before any toll was incurred. That is a structurally sound position: the platform is never chasing payment after the fact. We had done comparable thinking on a property maintenance project, where we used Stripe Connect's delayed payout system to hold funds until work was completed, achieving an escrow-like outcome without the legal complications of third-party escrow services. The underlying logic is similar: design the financial model around what you can control, rather than what requires third-party cooperation. ## Starting With Mid-Tier Providers to Build a Track Record One of the strategic recommendations we made on the toll management project was about sequencing. Rather than approaching the largest, most established toll operators first, the smarter move was to begin with mid-tier providers who carry less risk aversion and are more likely to engage with a new entrant on reasonable terms. Mid-tier providers have their own reasons to cooperate. A partnership with a platform that aggregates customers across multiple toll networks is attractive to a provider who does not dominate the market. They gain exposure to customers who would otherwise be using a competitor's network by default. The platform gains its first formal integration relationship, which is the thing it needs to take to the next conversation. #### What a track record actually looks like A track record in this context is evidence that the platform handles data responsibly, that the technical integration is stable, that customer complaints are low, and that the commercial relationship is uncomplicated. A mid-tier provider who has worked with you for six months and found you easy to deal with is a reference. That reference carries weight with a larger operator in a way that a pitch deck never will. When negotiating with mid-tier providers, be explicit about your long-term roadmap. Providers who understand that you are building toward broader integration, and that their cooperation is a named part of that story, tend to be more engaged than those who see themselves as a transaction. ## How to Structure the Conversation With an Established Operator When the time came to open conversations with more established operators on the toll management project, we had the preloaded credit model running and a small but real operational history to point to. That changed the nature of the conversation considerably. The structure we recommend for these conversations reflects what incumbents actually need to hear. They need to know you understand their operational concerns, not just your own product ambitions. They need to see evidence that you are a stable operator. And they need a clear articulation of [what the commercial arrangement looks like](https://weareaffective.com/learning-centre/5-reasons-your-app-needs-to-reflect-well-on-your-brand), because "we would like API access" without a commercial framework is a request, not a basis for a conversation. #### The structure that works 1. Open with your operational history, not your product vision. Volume processed, customer numbers, incident rate, how complaints were handled. 2. Name the specific integration you are asking for and what it replaces in your current model. Show you have already solved the problem another way, and that integration makes it cleaner. 3. Propose a trial scope with defined success criteria. A six-month pilot with one vehicle class on one network is easier to say yes to than an open-ended full integration. 4. Outline what you offer them commercially. Customer reach, referral volume, co-marketing, or revenue share depending on what fits. The conversation on the drinks industry trading platform we worked on taught us something related. We inherited a tightly coupled system with no API layer, and the third-party developer was slow to respond. The breakthrough came from taking ownership of the specification ourselves. We wrote the API spec, worked to it, and had the developer implement it. Taking the lead on the spec broke the deadlock. That principle applies to operator negotiations too: come with specifics, not requests. ## What Evidence Actually Moves Incumbents After the conversations we have had on projects like the toll management platform, the drinks industry trading platform, and the memory-sharing proof-of-concept where we switched from Spotify to Deezer, a pattern has emerged about what actually moves established operators. It is not enthusiasm for the product. It is not projected market size. It is evidence that you are operationally competent and commercially rational. The most useful evidence falls into three categories. The first is stability data: uptime, transaction success rates, error handling logs. These tell an operator that connecting to your platform will not create incidents they have to manage. The second is customer conduct data: complaint rates, resolution times, how disputes are handled. These tell them that their customers, if they interact with your platform, will not have a bad experience they associate with the operator. The third is commercial clarity: a clear statement of terms, a defined liability position, and a named commercial benefit to them. According to [Paddle (ProfitWell)](https://www.paddle.com/studios/shows/profitwell-report/integration-benchmarks), software with even one integration has over 10% higher retention than software with none, which gives you a genuine commercial argument to make: integration benefits both sides. What does not move them is the roadmap. Incumbents have seen many roadmaps. They have watched early-stage products project confident growth curves and then quietly disappear. Showing them [what you have built and how it performed](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) is worth considerably more than showing them what you plan to build. ## When to Stop Waiting and Build Around the Gap Instead There is a point in any integration negotiation where continuing to wait for a yes becomes more expensive than accepting that the answer is no and redesigning around it. We have hit that point on more than one project, and the pattern is consistent. The longer a product waits on a third-party integration that has not materialised, the more it shapes the product around a capability it does not yet have, and the harder the eventual redesign becomes. On the production management product we worked on for the motion picture industry, we initially expected to integrate directly with existing platforms used for storing [production documents](https://weareaffective.com/learning-centre/what-film-industry-document-portal-users-taught-us-about-designing-for-people-wh). When we finally gained access, we found the systems were far more locked down than anticipated. Rather than continuing to wait, we pivoted to ingesting emails tied to specific roles within a production, processing data indirectly without a direct integration into the third-party platforms. It was not the original plan. It worked. On the memory-sharing proof-of-concept project, we initially looked at integrating with Spotify for short audio clips. Spotify lacked a robust API for clips, and users would have needed a Spotify account. We switched to Deezer, which had a robust API, supported clips, and did not require users to be logged in. The technical route became simpler because we were using the official API in the way Deezer intended, meaning we were fully compliant without workarounds. There was also an upside we had not planned for: when [users wanted to hear a full track](https://weareaffective.com/learning-centre/what-curiosity-looks-like-in-a-first-session-and-why-most-products-design-past-i), there was a natural upsell to a Deezer subscription, creating an affiliate referral revenue stream alongside the product itself. Set a decision deadline at the start of any integration negotiation. If formal agreement has not been reached by a defined date, the product needs a plan that does not depend on it. This is the thing that keeps the product moving while the negotiation continues. ## Staging Integration Into a Product Roadmap The approach we recommended and the client accepted on the toll management project was a staged one. Launch with the preloaded credit model, establish credibility, pursue API integrations once the platform had demonstrated it was a serious operator. That staging was not a compromise. It was the right architecture for a product entering a market where access depends on trust that has to be earned. Staging integration into a roadmap requires being honest with stakeholders about what [the product can do at each stage](https://weareaffective.com/learning-centre/how-to-spot-a-product-vision-that-wont-survive-first-contact-with-users), and what it cannot. A staged roadmap looks something like this for a platform in this position. | Stage | Model | What it requires | What it builds | | --- | --- | --- | --- | | Launch | Preloaded credit via corporate accounts | Direct commercial accounts with providers | Live transaction data and operational history | | 6-12 months | Mid-tier provider API integration | Track record, defined trial scope | First formal integration reference | | 12-24 months | Tier-one provider negotiation | References, stability data, commercial proposal | Full integration coverage across key networks | The value of making this explicit in the roadmap is that it sets expectations correctly for the client, for any investors involved, and for the product team. Everyone knows what the product is in each stage, and nobody is waiting for an integration that has not been agreed before considering the product viable. The preloaded credit model is a working product. That distinction matters. ## Conclusion The toll management project changed how we think about integration planning on any product that depends on access controlled by an established operator. The lesson is that API access is a relationship outcome, and relationships take time to build when you are the new entrant and the incumbent has nothing obvious to gain from cooperating quickly. What we brought away from that project was a cleaner framework for sequencing. Map the landscape before committing to an architecture. Understand the incumbents' concerns before making the approach. Build a working product on a model that does not depend on their cooperation. Use that working product to earn the credibility that eventually opens the door to the conversations you wanted from the start. The preloaded credit model on the toll management platform was not a workaround. It was the right answer for that stage of the product's life. The staged approach to API integration was not a fallback. It was the honest plan, built around what we could control rather than what required someone else to say yes. If you are building a product that faces this kind of access challenge, the earlier you have this conversation the better. The decisions made in the first few months of architecture planning either give you room to manoeuvre or box you in. We are happy to talk through where your product sits and what the options look like. [Let's talk about your integration strategy.](https://weareaffective.com/get-started) ## Frequently Asked Questions Why is getting API access from established operators a negotiation rather than a technical task? Incumbent operators have no commercial incentive to help a new entrant succeed, and they hold sensitive customer data that they will only share once trust has been established. Before any technical planning begins, you need to understand what it would take for a provider to trust you enough to engage at all. Chasing API documentation from a provider who has not agreed to work with you is wasted effort. What did the toll provider landscape actually look like when you mapped it? The landscape was highly fragmented, with no consistent API or shared infrastructure across providers. Fee structures varied widely, with some networks charging by vehicle axle count and others applying a flat rate, and payment methods differed from provider to provider. This fragmentation was structural, meaning it was not something that would eventually be resolved on its own. What do incumbent operators typically need before they will share data with a new entrant? Operators need trust in the party asking, legal agreement on liability, and confidence that the integration will not cause problems for their existing customers. A new product with no track record gives them nothing to assess any of those things on. Demonstrating that you are a serious, capable operator is what creates the conditions for that conversation to happen. How did you approach building a product when you could not yet access the incumbent providers' systems? The approach was to build a working product that did not depend on cooperation from incumbents in the first instance. That working product then served as evidence of capability and seriousness, and it was ultimately what opened the door to further negotiations. Demonstrating a functioning product carries far more weight than a pitch or proposal alone. What is the risk of skipping the landscape mapping stage and going straight to architecture? Without mapping the landscape first, you risk committing to an architecture built on assumptions that turn out to be false. In the toll management case, the assumption that providers would have accessible, consistent APIs proved to be incorrect, which would have caused significant rework if discovered later. Mapping the real landscape before making technical decisions saves considerable time and cost. Does this approach to API access apply beyond toll management? Yes, the same dynamics appear in any regulated or incumbent-dominated market where third parties control access to data or infrastructure. The lesson from the toll management project has since changed how the team approaches integration planning on any product that depends on third-party data access. The core question is always the same: what does it take to earn the right to have the technical conversation. What is the most common mistake teams make when planning integrations with established platforms? The most common mistake is treating integration as a development task from the outset, assuming that API documentation exists and that credentials can simply be obtained. This approach works in open-access markets but fails when incumbents have operational and commercial reasons to be selective about who they share data with. Reorienting your energy towards credibility-building first changes the outcome significantly. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.