Live demo

Gids

Wat is API-integratie, uitgelegd voor reisbedrijven

Een API-integratie is een koppeling waarmee twee softwaresystemen gegevens uitwisselen en acties in gang zetten zonder dat iemand iets overtypt. Deze gids legt uit hoe het werkt aan de hand van één hotelboeking die onderweg is tussen een reiziger, een boekingsplatform, een leveranciers-API en een betaalgateway.

  • Eén verzoek, één antwoord
  • REST, XML, SOAP en webhooks
  • Eén boeking gevolgd door vier systemen
  • Hoe integraties worden getest

De definitie

Wat is API-integratie, in gewone taal

API staat voor application programming interface: de regels die een systeem publiceert zodat andere software ermee kan praten. API-integratie is het werk om uw platform aan zo'n interface te koppelen, zodat gegevens stromen en acties automatisch plaatsvinden.

In de reisbranche is dat platform meestal een boekingssysteem zoals Reisboekingssoftware, en de interface is van een leverancier, een betaalgateway of een bedrijfstool. Onze pagina Reis-API-integratie legt uit hoe PHPTRAVELS deze koppelingen levert, en Alle integraties toont de leveranciers die al zijn aangesloten.

  • Gegevens uitwisselen

    Tarieven, beschikbaarheid, klantgegevens en statusupdates gaan in een gestructureerd formaat van systeem naar systeem.

  • Acties automatiseren

    Zoeken, boeken, betalen, annuleren en afstemmen gebeuren als verzoeken, niet als stappen die iemand met de hand herhaalt.

  • Resultaten volgen

    Elke aanroep draagt een referentie, zodat een mislukte boeking kan worden herleid tot het verzoek dat de oorzaak was.

Verzoek

POST /v1/hotels/availability HTTP/1.1Host: api.supplier.exampleAuthorization: Bearer sk_test_••••••••Content-Type: application/json{  "city": "DXB",  "check_in": "2026-11-12",  "check_out": "2026-11-14",  "guests": 2,  "currency": "USD"}

Antwoord

HTTP/1.1 200 OKContent-Type: application/jsonX-Request-Id: req_7f3a91{  "hotel": "Palm Marina Hotel",  "room": "Deluxe, 2 adults",  "rate": { "amount": 438.00, "currency": "USD" },  "refundable": true,  "rate_key": "rk_19d2c7"}
Voorbeeldaanroep naar een fictieve hotelleverancier. Veldnamen, endpoints en bedragen verschillen per leverancier.

Anatomie van één API-aanroep

  1. 1

    Endpoint en methode

    Het adres van de bewerking en het werkwoord dat erop wordt gebruikt: POST naar availability betekent zoeken naar kamers.

  2. 2

    Authenticatie

    Een sleutel, token of handtekening bewijst wie er aanroept. Leveranciers geven aparte inloggegevens uit voor sandbox en productie.

  3. 3

    Payload

    De gestructureerde invoer: stad, data, gasten en valuta. De documentatie van de leverancier definieert elk veld.

  4. 4

    Statuscode

    Een getal dat zegt hoe de aanroep verliep: 200 is geslaagd, 4xx een probleem met het verzoek, 5xx een probleem aan de kant van de leverancier.

  5. 5

    Verzoek-ID

    Een identificatie die beide kanten bewaren. Als support vraagt wat er met een boeking is gebeurd, is dit waarop ze zoeken.

  6. 6

    Antwoordbody

    Het antwoord in het formaat van de leverancier, dat uw platform vertaalt naar zijn eigen kamers, tarieven en voorwaarden.

Eén boeking, vier systemen

Wat API-integratie doet tijdens een hotelboeking

Volg één verblijf van twee nachten van zoekopdracht tot voucher. Elke pijl is een API-aanroep; de reiziger ziet alleen de eerste en de laatste.

  1. 01ReizigerBoekingsplatformZoekt hotels in Dubai, twee nachten, twee gasten
  2. 02BoekingsplatformLeveranciers-APIBeschikbaarheidsverzoek met data, gasten en valuta
  3. 03Leveranciers-APIBoekingsplatformKamers, tarieven, voorwaarden en een rate key
  4. 04BoekingsplatformReizigerResultaten getoond met uw opslag en valuta toegepast
  5. 05BoekingsplatformLeveranciers-APIPrijscontrole op de gekozen rate key vóór betaling
  6. 06BoekingsplatformBetaalgatewayBetaalautorisatie voor het totaalbedrag
  7. 07BetaalgatewayBoekingsplatformGeautoriseerd, ondertekende webhook ontvangen
  8. 08BoekingsplatformLeveranciers-APIBoekingsverzoek met gastgegevens
  9. 09Leveranciers-APIBoekingsplatformBevestigingsnummer en annuleringsvoorwaarden
  10. 10BoekingsplatformReizigerVoucher, factuur en boekingsreferentie

Het platform in het midden is waar API-integratie leeft: het vertaalt tussen het scherm van de reiziger en het formaat van elke leverancier, en het bewaart elke referentie.

Dezelfde volgorde geldt voor Vluchtboekingssoftware met een GDS, Touroperator software met een activiteitenleverancier en Betaalgateway-integratie met elke gateway; alleen de veldnamen veranderen.

Integratiestijlen

REST, XML, SOAP, webhooks en GraphQL

Leveranciers publiceren hun interfaces in verschillende stijlen. De stijl wordt bepaald door de documentatie van de leverancier, niet door voorkeur, dus een reisplatform moet ze allemaal spreken.

  • REST en JSON

    JSON
    Gegevensformaat
    JSON-documenten
    Transport
    HTTP-methoden: GET, POST, PUT, DELETE
    Gebruikelijk in de reisbranche
    Nieuwere API's voor vluchten, hotels, activiteiten en betalingen
    Sterk punt
    Compacte payloads en brede ondersteuning in ontwikkeltools
    Let op
    Losjes gespecificeerd; elke leverancier interpreteert REST anders

  • XML en SOAP

    XML
    Gegevensformaat
    XML-documenten, vaak met een strikt schema
    Transport
    HTTP POST met een SOAP-envelop of kale XML
    Gebruikelijk in de reisbranche
    GDS, bedbanks en gevestigde hotel- en toursystemen
    Sterk punt
    Formele contracten, handtekeningen en servicedefinities
    Let op
    Omslachtige berichten en zwaardere verwerking

  • Webhooks

    EVENT
    Gegevensformaat
    JSON of XML, verstuurd door de andere kant
    Transport
    HTTP POST naar een URL die u registreert
    Gebruikelijk in de reisbranche
    Betaalresultaten, statuswijzigingen van boekingen, ticketingupdates
    Sterk punt
    Geen polling; uw platform krijgt bericht zodra er iets gebeurt
    Let op
    Handtekeningen moeten worden gecontroleerd en herhalingen afgevangen

  • GraphQL

    QUERY
    Gegevensformaat
    JSON, gevormd door de query die u verstuurt
    Transport
    Eén enkel HTTP-endpoint
    Gebruikelijk in de reisbranche
    Sommige nieuwere distributieplatforms en interne API's
    Sterk punt
    Vraag precies de velden op die u nodig hebt
    Let op
    Ondersteuning door leveranciers in de reisbranche is nog zeldzaam

API-integratie versus API-ontwikkeling

API-integratie

Koppelt uw product aan een interface die al bestaat. De leverancier bezit de API; u bouwt de client, de mapping en de regels eromheen.

API-ontwikkeling

Creëert een interface die andere systemen gebruiken om met uw product te koppelen, zoals een B2B-API die de tools van uw agenten kunnen aanroepen. U bezit het contract en zijn versies.

Veel reisprojecten hebben beide nodig: het platform integreert leveranciers aan de ene kant en publiceert zijn eigen API aan agenten en partners aan de andere kant.

Voor en na

Wat er verandert als systemen gekoppeld zijn

Dezelfde vijf stappen van een boeking, met de hand gedaan via leveranciersportalen en gedaan via API-integratie.

Zoeken

Zonder integratieHandmatig

Een agent opent elk leveranciersportaal en kopieert prijzen in een offerte.

Met API-integratieAutomatisch

Eén zoekopdracht gaat naar elke gekoppelde leverancier en levert één lijst op.

Prijs

Zonder integratieHandmatig

De opslag wordt in een spreadsheet toegevoegd; het tarief kan al gewijzigd zijn als de offerte wordt verstuurd.

Met API-integratieAutomatisch

Opslag, belastingen en valutaregels gelden op het moment van het antwoord; het tarief wordt vóór betaling opnieuw gecontroleerd.

Boeken

Zonder integratieHandmatig

Gastgegevens worden overgetypt in het leveranciersportaal; typefouten worden boekingsfouten.

Met API-integratieAutomatisch

Gegevens worden één keer verstuurd, gevalideerd en opgeslagen met de bevestiging van de leverancier.

Betalen

Zonder integratieHandmatig

De betaling wordt apart geïnd en later aan de boeking gekoppeld.

Met API-integratieAutomatisch

Autorisatie, incasso en terugbetaling zijn gekoppeld aan de boekingsreferentie.

Service

Zonder integratieHandmatig

Annuleringen en wijzigingen betekenen nog een login en nog een e-mail.

Met API-integratieAutomatisch

Wijzigingen en annuleringen lopen via dezelfde koppeling en werken het dossier bij.

Waar API-integratie voorkomt in een reisplatform

Woordenlijst

Termen die u tegenkomt in API-documentatie

Twaalf woorden die in bijna elk ontwikkelaarsportaal van leveranciers voorkomen, gedefinieerd zoals ze in de reisbranche worden gebruikt.

  • API

    Application programming interface: de gepubliceerde regels om met een systeem te praten.

  • Authenticatie

    Bewijzen wie er aanroept, met een API-sleutel, een bearer token, een handtekening of een goedgekeurd IP-adres.

  • Certificering

    De beoordeling van uw integratie door de leverancier voordat productie-inloggegevens worden uitgegeven.

  • Endpoint

    Eén adres voor één bewerking, zoals zoeken, boeken of annuleren.

  • Idempotentie

    Hetzelfde verzoek twee keer versturen levert één resultaat op, wat dubbele boekingen en afschrijvingen voorkomt.

  • Mapping

    De velden, codes en namen van de leverancier vertalen naar het eigen datamodel van uw platform.

  • Payload

    De gegevens die in een verzoek of antwoord worden meegestuurd, meestal JSON of XML.

  • Rate limit

    Het aantal aanroepen dat een leverancier per seconde of per dag toestaat voordat hij ze begint te weigeren.

  • Verzoek en antwoord

    Eén aanroep: uw platform vraagt, de leverancier antwoordt, en beide kanten loggen het.

  • Sandbox

    Een testomgeving met fictieve voorraad en testkaarten waar niets echt wordt geboekt of afgeschreven.

  • Statuscode

    Het HTTP-getal dat het resultaat samenvat: 200 geslaagd, 401 niet geautoriseerd, 429 rate limit bereikt, 500 leveranciersfout.

  • Webhook

    Een aanroep de andere kant op: de leverancier of gateway meldt uw platform wanneer er een gebeurtenis plaatsvindt.

Testen en scope

Hoe een reis-API-integratie wordt getest voordat hij live gaat

Een integratie is pas klaar als de foutpaden zich goed gedragen. Een testrun tegen de sandbox van de leverancier dekt de onderstaande gevallen vóór certificering en de overstap naar productie-inloggegevens.

integratietests uitvoeren

leverancierssandbox, negen gevallen

  • OK: Authenticatie met geldige en verlopen inloggegevens
  • OK: Ongeldig verzoek geweigerd met een leesbare foutmelding
  • OK: Time-out van de leverancier afgehandeld zonder hangende boeking
  • OK: Rate limit gerespecteerd en opnieuw geprobeerd na de wachttijd
  • OK: Prijswijziging opgevangen bij de controle en getoond vóór betaling
  • OK: Dubbele verzending geeft de eerste boeking terug, geen tweede
  • OK: Annulering toegepast en kosten berekend
  • OK: Terugbetaling uitgevoerd op de oorspronkelijke betaling
  • OK: Boekings-, betaal- en leveranciersreferenties stemmen overeen

Alle gevallen geslaagd, klaar voor certificering

Wat de scopebepaling van u nodig heeft

  1. 1Leveranciersovereenkomst, documentatie en sandbox-inloggegevens
  2. 2Markten, valuta's, producten en gebruikersrollen
  3. 3Scope van zoeken, boeken, wijzigen, annuleren en terugbetalen
  4. 4Certificeringseisen en het proces voor productietoegang

Klaar om een leverancier te koppelen

PHPTRAVELS integreert leveranciers, gateways en bedrijfstools in een zelf gehost platform dat met broncode wordt geleverd. Bekijk Prijzen voor de drie eenmalige plannen, of vraag ons naar een specifieke API.

Demo aanvragenNeem contact op

Lees verder

Vragen

Vragen over API-integratie, beantwoord

Korte antwoorden op de vragen die mensen stellen vóór hun eerste integratieproject.

Praat met sales

API-integratie is een koppeling waarmee twee softwaresystemen automatisch gegevens uitwisselen en acties in gang zetten. Het ene systeem stuurt een gestructureerd verzoek, het andere geeft een gestructureerd antwoord terug, en beide volgen afgesproken regels voor beveiliging en gegevens.

In de reisbranche koppelt het een boekingsplatform aan leveranciers van vluchten, hotels, tours of auto's, betaalgateways en bedrijfstools. Het ondersteunt zoeken, prijsvalidatie, boeken, annuleren, terugbetalen en afstemmen zonder overtypen.

REST is een architectuurstijl die meestal JSON over HTTP uitwisselt. XML is een gegevensformaat dat nog gangbaar is bij GDS- en bedbankleveranciers, vaak verpakt in SOAP. Het contract en de documentatie van de leverancier bepalen welke u gebruikt.

Dat hangt af van de toegang bij de leverancier, de endpoints binnen de scope, certificering, mappingregels en randgevallen bij boekingen. Een betrouwbare schatting volgt na een beoordeling van de documentatie, de inloggegevens en de workflows die u nodig hebt.

Test authenticatie, geldige en ongeldige verzoeken, time-outs, rate limits, prijswijzigingen, dubbele verzendingen, annuleringen, terugbetalingen en afstemming. In productie moet elk verzoek herleidbaar zijn tot een boekingsreferentie.

Nee. Integratie koppelt uw product aan een bestaande API; ontwikkeling creëert een interface waarmee anderen koppelen. Reisplatforms hebben vaak beide nodig: leveranciers geïntegreerd aan de ene kant en een B2B-API gepubliceerd voor partners aan de andere kant.

Verder ontdekken

Meer over het platform