How We Built a Movie Ticketing Portal That Processed $274,000 in Sales — And What Nobody Tells You About Third-Party APIs

Building a transactional product for the first time is humbling.

You think it's about writing good code. It isn't. It's about navigating people, legacy systems, ambiguous contracts, and that one vendor whose documentation hasn't been updated in three years.

This is the story of how our team of 4 built a movie ticketing portal from scratch — integrated with four cinema chains, served traffic across web, iOS, and Android, and averaged 100 transactions a day with a 90%+ success rate. Over two years, the platform generated over $274,000 in ticket sales.

Here's what we actually learned.

The Brief Sounded Simple

Integrate with major cinema chains. Show showtimes. Let users buy tickets. Display ratings from IMDb and Rotten Tomatoes. Ship it.

Simple enough — until you realise that each cinema chain runs its own proprietary ticketing stack, often built on legacy enterprise software, sometimes outsourced to a third-party media vendor, and almost never designed with external integrators in mind.

That gap between "integrate with their API" and what it actually takes? That's what this post is about.

The Vendor Problem No One Prepares You For

Our first major integration was with a large cinema chain. Their ticketing system ran on a legacy enterprise platform — a Windows-based, MS-SQL-backed setup called VISTA, which managed everything from theatre schedules to seat inventory. The challenge? Their development wasn't done in-house. They had outsourced it to a media technology partner.

So to integrate with them, we actually needed to negotiate with their vendor.

This meant a three-way conversation: us, the cinema chain's internal team (who understood the business requirements), and the vendor's developers (who understood the actual API surface). Nobody had the full picture. Everyone was waiting on someone else.

What followed was weeks of:

• Understanding how VISTA synced theatre and schedule data via DLL files under a .NET framework

• Setting up two dedicated personal servers on our side to host the VISTA Remote CS database — because that's what the integration required

• Scoping and filtering their vendor's API catalogue down to only what we actually needed for the transaction flow. Not everything on offer was necessary. Not everything was priced reasonably. The filtering exercise alone saved significant budget.

• Testing every API endpoint ourselves before a single line of wrapper code was written

One thing I learned early: never assume the vendor's API list is your shopping list. Scope what you need, test what you'll actually use, and push back on everything else.

Protecting the Mobile Teams from Complexity

Once the cinema integrations were stable, the next challenge was internal: how do you expose this to iOS and Android teams without making their lives miserable?

Our mobile developers operated on a build cycle. Every API change on our side could mean a new app build on theirs — a slow, expensive process. So the principle we adopted was maximum abstraction.

We built a wrapper API layer that sat between the vendor integrations and all front-end clients — web, iOS, and Android. The wrapper had one job: absorb complexity on our side so the mobile teams didn't have to.

• Internal vendor data formats? Hidden behind clean, normalised responses.

• Retry logic, error handling, edge cases in seat availability? All our problem.

• Cinema-specific transaction flows? Unified into a single consistent interface.

This meant we could update, fix, or even swap an underlying cinema integration without touching the mobile contract. The mobile teams shouldn't need to understand how VISTA works. That's not their concern. And this principle — high-level abstraction at the boundary layer — is one I've carried into every API design since.

The Data Problem: Mapping Movies at Scale

Here's something that surprised me: connecting movies to the right search categories and theatre listings was its own engineering problem.

Movies needed to be mapped to content categories on the platform. Theatres needed to be matched to physical business listings. And cinema chains had hundreds of venues across the country — around 200 for one chain, 150 for another, and dozens more for others.

We built an auto-mapping system using regex and pattern matching. It handled roughly 75–80% of cases. The remaining 20–25% required manual mapping — which we tracked and managed carefully.

On top of that, we built a suite of automated cron jobs to keep the platform fresh:

• IMDb and Rotten Tomatoes ratings, updated regularly via sourced data

• Critics reviews from well-known film journalists

• Seat availability labels (Full, Almost Full, Available)

• Show counts per theatre, movie digest scores, related trailers via YouTube's API

• Notifications before a movie's release window

• Automatic deactivation of inactive theatres

Each of these sounds small in isolation. Together, they were what made the product feel alive — like something users could actually trust.

The Result

100 transactions a day. 90%+ success rate. $274,000 in sales over two years. 4 Engineers.

No heroics. Just careful scoping, strong abstraction, and a lot of coordination work amongst different stakeholders that never shows up in a commit log.

The Takeaway

Third-party integrations are never purely technical problems. The real work is in understanding who owns what, scoping aggressively, and building your internal APIs to absorb external complexity — not pass it downstream.

If your mobile teams are asking questions about your vendor's data format, your abstraction layer has already failed.