<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/">
    <title>FX-Port Blog</title>
    <link href="https://blog.fx-port.com/feed.xml" rel="self" />
    <link href="https://blog.fx-port.com" />
    <updated>2026-08-29T04:06:00+02:00</updated>
    <author>
        <name>Tom S</name>
    </author>
    <id>https://blog.fx-port.com</id>

    <entry>
        <title>FX-Port vs. the Typical Flight API: Built for Travel Agencies, Not Just Developers</title>
        <author>
            <name>Tom S</name>
        </author>
        <link href="https://blog.fx-port.com/fx-port-vs-the-typical-flight-api-built-for-travel-agencies-not-just-developers/"/>
        <id>https://blog.fx-port.com/fx-port-vs-the-typical-flight-api-built-for-travel-agencies-not-just-developers/</id>
        <media:content url="https://blog.fx-port.com/media/posts/5/fx-port-flights-api.jpg" medium="image" />
            <category term="Flights"/>
            <category term="API"/>

        <updated>2026-08-29T04:06:00+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://blog.fx-port.com/media/posts/5/fx-port-flights-api.jpg" alt="" />
                    Most teams evaluate a flight API the way they’d evaluate any other&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://blog.fx-port.com/media/posts/5/fx-port-flights-api.jpg" class="type:primaryImage" alt="" /></p>
                <p>Most teams evaluate a flight API the way they’d evaluate any other API: read the docs, run a test call, check the response shape. That tells you almost nothing about what it’s actually like to run a travel business on top of it.</p><p>The real test shows up later. It’s the certification process that appears after the demo call. The fee line you didn’t notice on the pricing page. The country your biggest customer flies to that the API barely covers. The invoice that only makes sense if your business settles in dollars.</p><p>None of that shows up in a sandbox. All of it shows up six months in.</p><h2 id="complex-before-youve-written-a-line-of-code">Complex before you’ve written a line of code</h2>
<p>A lot of flight distribution APIs — especially the legacy GDS-style ones — treat access as something you earn. Certification calls. Technical review. A commercial agreement to sign before you get a production key. Weeks, sometimes months, between “we’re interested” and “we can actually book a ticket.”</p><p>That process exists for real reasons in a huge, mature industry. It’s also completely disconnected from how a modern travel business wants to move.</p><p>FX-Port skips it. No approval queue, no agreement to sign, no deposit. Create an account, generate a key, and your first search call works immediately. The sandbox is free and unlimited, so you can build the entire integration before you fund a single dollar of live balance.</p><h2 id="the-fee-schedule-you-dont-see-until-youre-already-committed">The fee schedule you don’t see until you’re already committed</h2>
<p>Ask around and you’ll hear the same story from a lot of agencies: the per-ticket economics looked fine on the sales call, and then the platform fee showed up. Or the minimum monthly commitment. Or a per-call charge stacked on top of the fare itself, so every search — successful booking or not — has a cost attached.</p><p>None of that is disclosed maliciously. It’s just how a lot of these commercial models are built, and it’s easy to miss until you’re already integrated and the first invoice lands.</p><p>FX-Port’s pricing is a single, visible formula: base fare plus taxes and fees plus your own commission equals what the traveler pays. What actually debits your balance is that total minus your commission. You set the markup. There’s no separate API fee layered underneath it, and no minimum commitment to hit before the economics make sense.</p><h2 id="strong-in-one-region-thin-everywhere-else">Strong in one region, thin everywhere else</h2>
<p>A lot of flight APIs are genuinely excellent — in the market they were built for. Deep content in North America or Europe, then noticeably thinner once you’re searching routes through the Gulf, North Africa, or other markets that weren’t the original design target. That’s not a flaw exactly; it’s just what happens when an API is built around one region’s GDS relationships and expanded outward later.</p><p>For a B2B travel business serving customers who don’t all fly the same handful of transatlantic routes, that gap is the whole ballgame.</p><p>FX-Port searches across GDS, NDC, low-cost carrier, and direct airline sources in a single call, and the supplier network keeps expanding behind the scenes — more connections, more coverage — without your integration having to change. Any change big enough to break a request ships under a new API version instead, so broader coverage doesn’t come at the cost of a rebuild.</p><h2 id="priced-like-the-provider-only-has-one-headquarters">Priced like the provider only has one headquarters</h2>
<p>This one’s easy to underestimate until you’re the agency it happens to: an API that settles exclusively in USD or EUR, funded by wire transfer, sometimes gated behind a credit check or a minimum deposit before you can go live. For a business operating in a market where none of that lines up cleanly with how money actually moves, it’s friction stacked on top of friction.</p><p>FX-Port is built around an agency balance that supports multiple currencies, with an exchange rate returned directly in the pricing response whenever a supplier prices in something other than your settlement currency — no separate lookup, no guessing. Funding that balance isn’t limited to a single rail, either; agencies in markets where card and wire access is slow or expensive can fund it in crypto.</p><h2 id="more-content-without-re-integrating">More content without re-integrating</h2>
<p>“More content” sounds like a vague sales pitch until you translate it into what it actually means for an agency: fewer “we don’t have that fare” moments. One search returning the best available price across every connected source, instead of a developer manually querying three different APIs and merging the results themselves.</p><p>That’s the entire premise of a unified travel API. It’s also the part that’s hardest to bolt on after the fact — which is exactly why it’s worth checking before you integrate, not after.</p><h2 id="when-a-narrower-api-is-genuinely-fine">When a narrower API is genuinely fine</h2>
<p>To be fair: if you’re building something that only ever needs one specific market or one narrow use case — a single-route booking widget for a single destination, say — a narrower, single-source API might be all you need, and simpler for it.</p><p>That’s a smaller set of businesses than the pitch decks suggest. Most travel agencies, OTAs, and wholesalers don’t stay narrow on purpose; they grow into new markets, new currencies, and new customer bases, and the API either grows with them or becomes the next thing they have to migrate off of.</p><h2 id="start-building">Start building</h2>
<ul>
<li><strong>Docs:</strong> <a href="https://docs.fx-port.com">docs.fx-port.com</a></li>
<li><strong>API keys:</strong> <a href="https://fx-port.com/dashboard/api">fx-port.com/dashboard/api</a></li>
<li><strong>Sign up:</strong> <a href="https://fx-port.com/register">fx-port.com/register</a></li>
</ul>

            ]]>
        </content>
    </entry>
    <entry>
        <title>FX-Port vs. Airalo and Holafly: The eSIM Choice for Travel Agencies, Not Just Travelers</title>
        <author>
            <name>Tom S</name>
        </author>
        <link href="https://blog.fx-port.com/fx-port-vs-airalo-and-holafly-the-esim-choice-for-travel-agencies-not-just-travelers/"/>
        <id>https://blog.fx-port.com/fx-port-vs-airalo-and-holafly-the-esim-choice-for-travel-agencies-not-just-travelers/</id>
        <media:content url="https://blog.fx-port.com/media/posts/4/Screenshot-2026-08-28-at-13.53.26.png" medium="image" />

        <updated>2026-08-28T13:52:02+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://blog.fx-port.com/media/posts/4/Screenshot-2026-08-28-at-13.53.26.png" alt="FX-Port esim" />
                    If a traveler asks the internet “best eSIM for my trip,” Airalo&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://blog.fx-port.com/media/posts/4/Screenshot-2026-08-28-at-13.53.26.png" class="type:primaryImage" alt="FX-Port esim" /></p>
                <p>If a traveler asks the internet “best eSIM for my trip,” Airalo and Holafly are probably the first two names that come back. That’s fair — both built large, well-run consumer eSIM brands, millions of users between them, apps that make buying a data plan for one trip almost effortless.</p><p>That’s exactly the point, and exactly why they’re the wrong comparison for a travel agency to be making.</p><p>A traveler needs a data plan for one trip. A travel agency needs infrastructure for every trip it sells, this year and next. Those are different problems, and they call for different platforms.</p><h2 id="both-are-excellent-at-the-thing-they-were-built-for">Both are excellent at the thing they were built for</h2>
<p>Worth saying plainly: Airalo and Holafly aren’t weak products. Both have since layered partner programs, reseller dashboards, and APIs on top of their consumer apps, and both make it genuinely easy for a business to start referring or reselling eSIMs.</p><p>But the core of each business is still a consumer app, built to acquire individual travelers directly. The partner layer sits on top of that — a way to extend a consumer brand outward, not a platform designed around how a travel agency actually operates.</p><p>That distinction matters more than it sounds like it should.</p><h2 id="where-the-esim-lives-in-your-business">Where the eSIM lives in your business</h2>
<p>Sell through a consumer eSIM brand’s partner program and connectivity becomes its own line item: its own login, its own dashboard, its own payment relationship, its own support queue, sitting next to — but separate from — everything else you sell.</p><p>On FX-Port, it isn’t separate. The eSIM sits in the same account, the same balance, and the same API as flights and hotels. One login for the agency. One integration for the developer. One place a booking, a hotel reservation, and an eSIM order all show up together, because they’re usually the same trip.</p><p>If your business is built around travel — not around connectivity as a category — that’s the difference that actually shows up in your workflow six months in.</p><h2 id="rates-built-for-resale-not-for-referrals">Rates built for resale, not for referrals</h2>
<p>Consumer partner programs are typically built around a commission on the retail price, or a discount off it. That works fine for an affiliate publishing a blog post or a creator with an audience.</p><p>It works less well for a travel agency that wants to set its own margin, bundle connectivity into a package price, or quote a corporate client a single number that includes the flight, the hotel, and the data plan.</p><p>FX-Port prices eSIMs the same way it prices everything else on the platform: wholesale, net rates that you mark up yourself. You decide the margin. You decide whether it shows up as a line item or gets folded into a package. Nobody’s fixed commission structure decides that for you.</p><h2 id="coverage-that-isnt-tied-to-one-brands-network">Coverage that isn’t tied to one brand’s network</h2>
<p>Because FX-Port’s eSIM catalog is sourced across multiple supplier networks behind a single API, coverage and reliability in any given destination don’t depend on one company’s carrier relationships. If one network has a gap or an outage in a given country, the platform isn’t limited to that single path — the same way flight search on FX-Port isn’t limited to a single airline or reservation system.</p><p>A single-brand consumer platform, by contrast, is exactly that: one brand’s inventory, one brand’s coverage map, one brand’s outages.</p><h2 id="funding-that-matches-how-agencies-actually-pay">Funding that matches how agencies actually pay</h2>
<p>An individual traveler is fine entering a card number for a single $12 eSIM. A travel agency is funding dozens of bookings a week, often across borders, often in a currency that doesn’t match wherever the eSIM company happens to be headquartered.</p><p>FX-Port’s agency balance supports funding in multiple currencies — including crypto, which matters more than it might sound for agencies operating in markets where card rails are slow, expensive, or simply unavailable for B2B volume. It’s one balance, funding every product on the platform, not a separate payment method to set up per supplier.</p><h2 id="the-customer-stays-yours">The customer stays yours</h2>
<p>This is the one that’s easy to underweight and expensive to get wrong.</p><p>Route a customer through an affiliate link or a co-branded partner page, and at some level, they’re a customer of the eSIM brand wearing your colors. Build on an API instead, and the eSIM is just a feature of your product — your booking flow, your confirmation email, your support channel, your brand, start to finish.</p><p>For an agency whose entire business is repeat trust — the client who’s booked through you for years, who has your WhatsApp number — that’s not a small detail. It’s the difference between adding a product and quietly handing off a piece of the relationship.</p><h2 id="when-airalo-or-holafly-is-genuinely-the-better-call">When Airalo or Holafly is genuinely the better call</h2>
<p>To be fair about it: if you’re an individual creator or a small affiliate site with an audience and no booking infrastructure of your own, a partner link to an established consumer brand is a perfectly sensible way to monetize that audience. You’re not running a travel operation — you don’t need one.</p><p>But that’s a different business than a travel agency, wholesaler, or OTA with its own customers, its own booking flow, and its own margin to protect. For that business, the question was never really “which eSIM app is best.” It’s “whose platform is actually built around mine” — and that’s a B2B travel platform, not a consumer app with a partner tier bolted on.</p><h2 id="start-building">Start building</h2>
<ul>
<li><strong>Docs:</strong> <a href="https://docs.fx-port.com">docs.fx-port.com</a></li>
<li><strong>API keys:</strong> <a href="https://fx-port.com/dashboard/api">fx-port.com/dashboard/api</a></li>
<li><strong>Sign up:</strong> <a href="https://fx-port.com/register">fx-port.com/register</a></li>
</ul>

            ]]>
        </content>
    </entry>
    <entry>
        <title>FX-Port eSIM API Is Now Live — Add Travel eSIMs to Your Platform With One Integration</title>
        <author>
            <name>Tom S</name>
        </author>
        <link href="https://blog.fx-port.com/fx-port-esim-api-is-now-live-add-travel-esims-to-your-platform-with-one-integration/"/>
        <id>https://blog.fx-port.com/fx-port-esim-api-is-now-live-add-travel-esims-to-your-platform-with-one-integration/</id>
        <media:content url="https://blog.fx-port.com/media/posts/3/fx-port-api-post.png" medium="image" />
            <category term="eSims"/>
            <category term="API"/>

        <updated>2026-08-27T23:06:39+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://blog.fx-port.com/media/posts/3/fx-port-api-post.png" alt="FX-Port API" />
                    A few weeks ago we opened the FX-Port API for flight bookings.
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://blog.fx-port.com/media/posts/3/fx-port-api-post.png" class="type:primaryImage" alt="FX-Port API" /></p>
                <p>A few weeks ago we opened the FX-Port API for flight bookings. Today eSIMs join it, on the exact same account, the same key, and the same balance you’re already using for flights.</p><p>If you’ve already integrated FX-Port, there’s nothing new to set up. Your existing key already has permission to call eSIM endpoints, your existing balance is what gets debited, and your existing dashboard is where flight bookings and eSIM orders now show up side by side. If you haven’t integrated yet, this is a good reason to start — one connection now covers two things a traveler needs in the same moment: a seat on the plane, and a way to get online once they’re off it.</p><h2 id="why-this-pairs-so-naturally-with-flights">Why this pairs so naturally with flights</h2>
<p>Selling a flight puts you right next to a question the traveler is about to ask themselves anyway: how am I getting connected when I land? An eSIM is one of the few travel add-ons that’s genuinely easy to attach — there’s no size, no seat, no date change to negotiate. It’s a QR code the traveler scans before they board or right after they land, and they’re online before they’ve found the taxi rank.</p><p>For an agency already booking flights through FX-Port, that makes eSIMs close to free upside. The integration is already done. This is one more product sitting on top of it, not a second stack to build and maintain.</p><h2 id="what-you-can-offer">What you can offer</h2>
<ul>
<li>Data plans across 190+ countries</li>
<li>Instant digital delivery — a QR code, not a physical SIM that has to ship or wait behind a counter</li>
<li>Wholesale, net pricing that you mark up yourself, not a fixed referral cut</li>
<li>Coverage sourced across multiple supplier networks, so it doesn’t depend on any single vendor’s gaps</li>
</ul>
<h2 id="where-the-docs-stand-right-now">Where the docs stand right now</h2>
<p>Flights has a full technical reference live at <a href="https://docs.fx-port.com">docs.fx-port.com</a> — request and response shapes, error codes, the works. eSIM endpoints are live and callable on that same key today; the dedicated written reference for them is landing on the docs site shortly, the same way hotels’ is. If you want to start wiring it up before that page goes live, reach out through the docs site and the team will walk you through the exact request format directly — no need to wait for the page to publish before you start building.</p><h2 id="same-key-same-responsibility">Same key, same responsibility</h2>
<p>Worth repeating for anyone new to the API through this post specifically: a Read+Write key can place real orders and charge your balance on eSIMs just as it does on flights. Keep it server-side — never in a mobile app, a front-end bundle, or a public repo.</p><h2 id="whats-next">What’s next</h2>
<p>Hotels documentation is close behind. And the same rule holds across every product on FX-Port: as more suppliers and more coverage get added behind the scenes, your integration doesn’t need to change to benefit from it.</p><h2 id="start-building">Start building</h2>
<ul>
<li><strong>Docs:</strong> <a href="https://docs.fx-port.com">docs.fx-port.com</a></li>
<li><strong>API keys:</strong> <a href="https://fx-port.com/dashboard/api">fx-port.com/dashboard/api</a></li>
<li><strong>Sign up:</strong> <a href="https://fx-port.com/register">fx-port.com/register</a></li>
</ul>

            ]]>
        </content>
    </entry>
    <entry>
        <title>FX-Port API Is Now Live for Integration — Start With Flights</title>
        <author>
            <name>Tom S</name>
        </author>
        <link href="https://blog.fx-port.com/fx-port-api-is-now-live-for-integration-start-with-flights/"/>
        <id>https://blog.fx-port.com/fx-port-api-is-now-live-for-integration-start-with-flights/</id>
        <media:content url="https://blog.fx-port.com/media/posts/1/fx-port-api-post.png" medium="image" />
            <category term="eSims"/>
            <category term="Transfers"/>
            <category term="Hotels"/>
            <category term="Flights"/>
            <category term="API"/>

        <updated>2026-08-22T16:13:20+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://blog.fx-port.com/media/posts/1/fx-port-api-post.png" alt="" />
                    FX-Port’s API is officially open for integration. If you’re a travel agency,&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://blog.fx-port.com/media/posts/1/fx-port-api-post.png" class="type:primaryImage" alt="" /></p>
                <p>FX-Port’s API is officially open for integration. If you’re a travel agency, OTA, or developer building on top of travel inventory, you can now plug directly into FX-Port and start selling flights through your own product — no sales calls, no signed agreements, no deposit.</p><p>Full documentation, code samples, and a self-serve dashboard are live now at <a href="https://docs.fx-port.com">docs.fx-port.com</a>.</p><h2 id="what-you-get-with-one-integration">What you get with one integration</h2>
<p>FX-Port gives you a single, unified API for the entire flight booking lifecycle — not just search:</p><ul>
<li><strong>Search</strong> for flights and get the best available fares</li>
<li><strong>Flexible date search</strong> to compare prices across a date range</li>
<li><strong>Price</strong> an offer to confirm the current fare before booking</li>
<li><strong>Book</strong> instantly, or <strong>hold</strong> a reservation and pay later</li>
<li><strong>Cancel</strong> a held reservation to release it cleanly</li>
<li><strong>Retrieve bookings</strong> and download ticket PDFs</li>
</ul>
<p>One API surface, one authentication model, one response format — regardless of where the fare is actually sourced from behind the scenes. You don’t manage multiple integrations or reconcile different data formats; you make one call and get back the best price available.</p><p>And it keeps getting better without any work on your end: FX-Port is continuously expanding its supplier network and adding more coverage. Your integration benefits automatically — no code changes required. We’re also committed to never breaking your existing integration; any major change ships under a new API version, so what you build today keeps working.</p><h2 id="get-started-in-three-calls">Get started in three calls</h2>
<pre><code class="language-bash">curl --request POST \
  --url https://api.fx-port.com/api/v1/get_flights \
  --header &#39;Authorization: Bearer fxp_live_YOUR_KEY&#39; \
  --header &#39;Content-Type: application/json&#39; \
  --data &#39;{
    &quot;origin&quot;: &quot;ALG&quot;,
    &quot;destination&quot;: &quot;CDG&quot;,
    &quot;departure_date&quot;: &quot;2026-09-15&quot;,
    &quot;cabin_class&quot;: &quot;economy&quot;,
    &quot;passengers&quot;: { &quot;adults&quot;: 1 }
  }&#39;
</code></pre>
<p>That’s search. Price the offer to confirm the fare, then book — tickets are issued immediately. Three calls, and you’re selling flights.</p><p>Sign up, grab a free sandbox key from your dashboard, and start building today. Switch to a live key against a funded balance whenever you’re ready to issue real tickets — same base URL, no separate environment to configure.</p><h2 id="pricing-you-can-explain-to-a-traveler">Pricing you can explain to a traveler</h2>
<p>Every offer comes back with a clean breakdown: the base fare, taxes and fees, your own commission, and the final price the traveler pays. You always know exactly what gets debited from your agency balance and exactly what you’re marking up — no guesswork, no hidden math.</p><h2 id="built-for-developers">Built for developers</h2>
<ul>
<li><strong>No approval queue.</strong> Create an account, generate a key, and your first call works immediately.</li>
<li><strong>Free, unlimited sandbox</strong> to build and test before you go live.</li>
<li><strong>Machine-readable docs</strong> (<code>/llms.txt</code> and <code>/llms-full.txt</code>) so AI coding assistants can integrate with accurate, up-to-date context.</li>
</ul>
<h2 id="whats-next">What’s next</h2>
<p>Flights are live and fully documented today. Hotels and eSIMs are already live on the API too, with dedicated documentation landing shortly. More products and more coverage are on the way — and every addition lands in your integration automatically.</p><h2 id="start-building">Start building</h2>
<ul>
<li><strong>Docs:</strong> <a href="https://docs.fx-port.com">docs.fx-port.com</a></li>
<li><strong>Sign up:</strong> <a href="https://fx-port.com/register">fx-port.com/register</a></li>
<li><strong>API keys:</strong> <a href="https://fx-port.com/dashboard/api">fx-port.com/dashboard/api</a></li>
</ul>

            ]]>
        </content>
    </entry>
</feed>
