Duffel API integration development for travel booking platforms

What does a Duffel API integration from DevoraX include?

The base scope is the integration and the layer you own around it. Duffel sits behind your own Node.js service rather than in your front end, so credentials never reach a browser and supplier behaviour can change without shipping a client release.

Inside that service we build the itinerary model. A connecting flight is not one product. It is two or more separately operated segments joined by a layover, and on a codeshare the carrier that sells a segment is not the carrier that operates it. We carry marketing and operating identity separately through the model instead of collapsing them into a single airline field, because any rule that depends on a carrier has to know which carrier it means.

Scoring and annotation sit on top of that structure. The full base scope is listed below, and so is what we quote separately. Order creation and ticketing are on the second list for a reason set out further down.

What Duffel work stands behind this page?

Barfly. It is a flight transfer risk assessment module on Node.js that integrates Duffel API data with heuristic algorithms to assess disruption risk for codeshare and non-codeshare itineraries, with React.js on the interface side. It runs inside got2.travel, a live travel product. Sameem Amjad, DevoraX's founder, architected the module as an engineer at Zencloud, from the Duffel integration to the risk heuristics. It was Zencloud's project for got2.travel. The write-up is at /projects/29.

That is one project, not a portfolio of them. What it evidences is the engineering: a Duffel integration taken into a live product, with domain logic built on top of it.

Where does the Barfly work stop?

At search and assessment. Barfly takes Duffel flight data and assesses transfer risk on codeshare and non-codeshare itineraries. Order creation, payment and ticketing are scoped and quoted as new work, so if your product needs booking through to an issued ticket, weigh that when you compare us against an agency that has already shipped it.

The stack is Node.js, with React.js on the interface side, and the risk model works from airline protocols and aviation variables. Native iOS and Android apps are quoted separately. Know the shape of the evidence before a call, not after one.

Who is this page for?

Travel booking platforms, OTAs and metasearch products that have decided to integrate Duffel and want the integration, and whatever sits on top of it, built once and properly.

The closest fit to the Barfly work is a platform whose difficulty is in the reasoning over itineraries rather than in the distribution itself. Connection risk, disruption exposure, ranking that is not purely price, or any rule set that has to know which carrier actually operates a segment. That is the problem Barfly addresses. If you are searching flights and displaying them with no derived logic on top, the integration is smaller than this page describes and you may not need an agency for it.

Corporate travel tools and vertical booking products with their own policy rules are the same shape of problem: rules that have to run over a normalized itinerary structure rather than over per-carrier formats.

How do you keep supplier, agent and traveller data separate?

This matters when more than one party lives inside your platform: agencies booking under their own accounts, suppliers beyond flights, or white-labelled partners with their own customers.

The method is the same on any platform. Tenancy belongs in the data model from the first migration rather than being retrofitted. Every row that belongs to a party carries that party's identifier, the identifier is derived from the authenticated session and never from a request parameter, and the check is enforced server-side on every read and write.

If a genuine multi-party marketplace is the product rather than a side effect of it, say so before we quote. That is a different build with a different data model at its centre, and we would scope it as its own project rather than as an extension of a Duffel integration.

What does the build look like, and what do you need from us?

It starts with a free 30-minute discovery call, after which you get a written fixed-price proposal with the scope stated line by line. Nothing begins before you have that document and have agreed to it.

What we need from you is a Duffel account and test credentials in your own name, because that account is a commercial relationship between you and Duffel and should never sit with a supplier. We also need the product decisions only you can make: which markets, which cabin classes, what happens when a search returns nothing, and what your rules are if we are building rules. If the scoring logic is yours, we need it written down before we quote it.

One named contact who can answer a question the same week is worth more than any process. Sameem Amjad runs the engagement. Usman is the other half of the team.

How is a Duffel integration priced?

Fixed price. There is no hourly billing. After the discovery call you get a written proposal with a fixed figure against a defined scope, and if the scope changes we requote in writing rather than letting a number drift upward.

Published starting points are $2,900 for MVP Starter and $7,500 for Growth, with Enterprise custom-scoped. Those are indicative starting points and not a quote for your build. A search integration dropped into an existing React front end and a full engine with its own rule set are different projects and will not carry the same number.

The reason we work this way is unglamorous. A fixed price moves the estimating risk onto us, which is where it belongs, and it gives you a figure you can take to a board rather than a range you have to defend.

What happens after launch?

You own everything. All code and IP transfer to you on final payment. The repository is yours, the Duffel account was always yours, and there is no license to renew and no runtime dependency on DevoraX.

Support is scoped and quoted separately, and it is worth saying what it is not. DevoraX is two named people, so there is no round-the-clock rota and we will not pretend there is. What we offer is a defined arrangement with an agreed response window during working hours, written into the proposal so you know what you bought before you buy it.

Taking the work in-house after handover is a normal outcome rather than a failure of the relationship. The handover document exists so that another engineer can pick the integration up without calling us.

When should you not hire DevoraX for this?

If your distribution requirement is GDS, meaning Amadeus, Sabre or Travelport, or direct NDC connections to carriers, hire a supplier who has those running in production. Nothing in the DevoraX portfolio includes them, and you should not fund the learning.

If you need someone on call around the clock for a live booking desk, two people cannot honestly provide it. If you need IATA accreditation, consolidator relationships or a regulated payments operation, those are commercial and regulatory problems rather than engineering ones and we do not solve them.

If you already have a working Duffel integration and want extra hands by the hour to extend it, the fixed-price model will frustrate you. And if the only thing you need is flight search rendered on a page with no derived logic above it, that is a smaller job than this page describes and you may not need an agency for it.