DevoraX is a software agency founded in 2019. We have built one Duffel API integration for a live travel product: Barfly Risk Engine, a Node.js system that pairs Duffel flight data with heuristic algorithms to score transfer risk on codeshare and non-codeshare itineraries in real time. It is live at got2.travel and the case study is public.
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 we set out further down.
Which build proves DevoraX has shipped this?
Barfly Risk Engine. It is a Node.js flight transfer risk assessment system that integrates the Duffel API with heuristic algorithms to produce real-time risk predictions for codeshare and non-codeshare itineraries, with React.js as the interface technology. The build also includes an AI travel assistant, disruption prediction and a global flight risk index. It is live at got2.travel and the full case study is at /projects/29.
The client reports 88% on-time performance and 78% flight risk prediction accuracy, describes user satisfaction as high, and gives the disruption prediction level as moderate. Those four figures are the whole of the reported numbers. DevoraX did not measure or audit them and how they were arrived at has not been published, so they are reproduced exactly as reported.
That is one project, not a portfolio of them. DevoraX has delivered 25 projects since 2019, each with a published case study. Barfly is the one that evidences Duffel.
What does the Barfly record not prove?
The published record covers the search and assessment path. It does not document order creation, payment or ticketing, so this page claims none. If your product needs booking through to an issued ticket, that is work we will scope and quote against proof that stops short of it.
Nor does it describe the internals. It states that the engine treats codeshare and non-codeshare itineraries as distinct cases, but not the schema behind that, so the data modelling described above is method rather than a delivered artefact. The same holds for the AI travel assistant, disruption prediction and risk index.
The project is categorised as Node.js Backend and AWS, but the technologies named for it are React.js and Node.js only. No hosting topology, database, cache or queue is published, so none is claimed. The risk model's inputs are given as airline protocols and aviation variables and no further. Barfly is a web product with no Android or iOS build. 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 what we have shipped 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 is. 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.
Be clear about the evidence first. The Barfly record documents no multi-tenant model, so nothing here claims we have shipped one, and no other page on this site is offered as proof of it either. What we will state is method. 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 24/7 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. We have not shipped 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.
Start with a scoping call
A free 30-minute call to work out what you are building and what is actually hard about it. If there is a fit you get a written fixed-price proposal. If there is not, we will say so on the call.
Book a call