Introduction
Integrating CTeleport with Your Systems
Why Integration Matters
Integrations are no longer a tech luxury—they're essential for efficient operations. They connect your systems, sync critical data, and eliminate time-wasting manual tasks. This means fewer delays and smoother workflows for industries like marine, aviation, and offshore.
Faster Flight Bookings
Forget endless forms and double data entry. With integration, booking flights becomes a one-click task, directly from your HR or crew planning software.
Fewer Errors, Less Risk
Mistyped names or wrong dates can mean missed flights or even legal issues. With C Teleport, traveller details are pulled directly from your HR system. In return, flight details like ticket numbers and times are pushed back automatically. No more copy-pasting. Just accurate data—every time.
Fully Synced, Always Up to Date
Book a flight, and your HR platform updates instantly. Crew planning, approvals, and reporting stay in sync, so nothing gets missed or delayed.
What do we support?
At C Teleport, we adapt to your needs, not vice versa. We support multiple integration methods and data formats to work with your existing tools.
Integration Options
1. Web Services / API (recommended)
Your system exposes an API. We connect, retrieve, and send data in your preferred format: JSON (recommended), XML, CSV, or others.
2. Database Access
Prefer a direct connection? Give us access to your database (MS SQL, MySQL, etc.) and we’ll handle the rest.
What can be integrated ?
- Traveller data: Automatically synced from HR, no manual input needed.
- Crew change data: Airports, dates, and traveller groups are pre-filled.
- Booking data: Bookings, changes, and cancellations are sent back to your HR system.
- Search from HR: After crew planning, launch a flight search with one click.
Suggested Implementation Timeline
Start simple, scale as needed. We recommend a phased approach:
Integration Step | Estimated Time | Reference |
---|---|---|
Sync traveller profiles | ~4 hours | Article |
Travel Request integration | ~4 hours | Article |
Crew change integration | ~4 hours | Article |
Send bookings data to HR system | ~20 hours | Article |
You can stop after the basics—or go further. But integrating traveller data is essential. It delivers the most significant time and error savings.
Ready to connect your systems and simplify crew travel?
👉 Let’s plan your integration: Schedule a demo
Flow
Here's the integration flow that we can establish to ensure flawless synchronization between C Teleport and your HR software.
1. Traveller integration
This is the most basic integration. It is also the minimum required integration to start using C Teleport. It should take between 4 and 20 hours depending on HR software infrastructure. If you estimate more time, please get in touch with us to discuss options.
Here, what crew managers will see:
When users enter traveller data while booking, we suggest surnames of traveller based on the information retrieved from your HR software. Users don't have to enter data manually and, therefore, avoid mistakes. C Teleport uses the first entered letters to find traveller for the suggestions.
Example message in JSON format
[
{
"last_name": "Smithsen",
"first_name": "John",
"dob": "1978-12-03", // YYYY-MM-DD format
"nationality": "GB", // 2-char ISO code
"gender": "M",
"doc_country": "GB", // 2-char ISO code
"doc_number": "UK36276372323",
"doc_expire": "2019-04-22", // YYYY-MM-DD format
"home_airport": "LON", // 3-char IATA-code of the home airport
"email": "smithsen@gmail.com", // Optional
"phone": "555123456789", // Optional
"id": "AS32231", // Optional
},
{
"last_name": "Smith",
"first_name": "Eugene",
"dob": "1976-11-12",
"nationality": "NL",
"gender": "M",
"doc_country": "NL",
"doc_number": "NL637643742",
"doc_expire": "2021-03-04",
"home_airport": "LON",
"email": "eugene.smith@gmail.com",
"phone": "555987654321",
"id": "SM3233",
}
]
Required data for traveller integration
Parameter | Format | Description |
---|---|---|
last_name | string | Last name |
first_name | string | First name |
dob | YYYY-MM-DD | Date of birth |
nationality | 2 letters | Nationality. 2-letter country code. Standard ISO-3166-1 alpha-2. |
gender | M or F | Gender |
doc_country | 2 letters | Passport issuance country. 2-letter country code. Standard ISO-3166-1 alpha-2. |
doc_number | string | Passport number. 9 char maximum. |
doc_expire | YYYY-MM-DD | Passport expiry date |
home_airport | 3 letters | IATA code of the closest airport for the Traveller. |
string | Optional. Email of the Traveller | |
phone | string | Optional. Phone of the Traveller |
id | string | Optional. ID number of the Traveller for backwards synchronisation |
Option 1.1: Call your API real-time during booking
Example GET request to your API
GET http://yourcompany.com/api/suggest_traveller?surname=SMITH
Here is the desired workflow:
You expose a webservice that will respond to GET
requests. You provide us with the URL address of the web service and establish security measures.
HTTP authentication password protected access or IP whitelist will be fine.
Your webservice responds with a list of people that are matching the surname.
Despite we recommend JSON format, we can accept any format of data and convert it to our required format on our side. So, your API may respond with JSON, XML, SOAP, CSV, plaintext or virtually any other format. In case of missing data, crewing managers will have to enter it manually.
Option 1.2: Cache data after calling you API
You expose an API that allows C Teleport caching all traveller data on a regular basis. Normal frequency is every hour. Then C Teleport retrieves data from you regularly, stores all cached data and serves users suggestions from cache. This option is the fastest in terms of performance.
Option 1.3: Uploading your data via our REST API
Example of request to our API
POST https://integrations.cteleport.com/passenger
Header: X-Api-Key: [your API key]
Body:
[
{
"id": "AS32231",
"last_name": "Smithsen",
"first_name": "John",
"dob": "1978-12-03",
"nationality": "GB",
"gender": "M",
"doc_country": "GB",
"doc_number": "UK36276372323",
"doc_expire": "2019-04-22",
"home_airport": "LON",
"email": "smithsen@gmail.com",
"phone": "1234567890"
}
]
We can receive data about your Travellers through our endpoint. We will provide you a special API key and you will send your data with it in the same format as used across this document. It will be instantly available for booking tickets.
2. Travel Request integration
Example of request to your webservice
GET http://yourcompany.com/api/travel_request?from=2025-05-03&to=2025-08-03
Example response
[
{
"requestId": "TR123", //Your id of the main entity which helps users to identify this entity on our UI"
"subRequestId": "SUBREQ123", //optional
"additionalInfo": { //filters
"AMS-RIX_departure_time": "08:00", //in local timezone of the airport
"AMS-RIX_flight_id": "your flight_id for this leg",
"RIX-JFK_departure_time": "08:00", //in local timezone of the airport
"RIX-JFK_flight_id": "your flight_id for this leg"
},
"hotel": {
"location": "Rotterdam",
"checkIn": "2025-05-21",
"checkOut": "2025-05-22"
},
"flight": {
"origin": "AMS",
"destination": "JFK",
"date": "2025-06-01",
"intermediateAirports": [
{
"airport": "RIX",
"date": "2025-05-30"
}
]
},
"details": {
"vehicle": {
"name": "Vessel One",
"flag": "NL",
"vehicleType": "Vessel"
}
},
"traveler": {
"id": "231", // Id of the traveler in your system, if we need it for delivering of data
"lastName": "Smithsen",
"firstName": "John",
"dob": "1978-12-03",
"nationality": "GB",
"gender": "M",
"docCountry": "GB",
"docNumber": "UK36276372323",
"docExpireDate": "2025-04-30",
"email": "test@test.nl",
"phone": "+3167212121"
}
}
]
Automatically Pre-Fill Travel Plans
By integrating your travel requests with C Teleport, you allow our platform to instantly fetch your planning data. That means faster booking, fewer errors, and a seamless experience from request to ticket.
Whether you operate in maritime, aviation, energy or corporate travel, this integration adapts to your specific industry needs.
Option 2.1 Your API or webservice
To integrate with C Teleport, your system needs to expose a simple API.
When a user selects a date, C Teleport will send a GET request to your web service. Your system should respond with all relevant crew change details scheduled for that date.
What Your API Must Return
Your webservice must provide 4 data groups: 1. Traveller details 2. Vehicle details (if relevant) 3. Either hotel or flight information 4. HR system identifiers
1) Traveller information:
Parameter | Format | Description |
---|---|---|
last_name | string | Traveller’s last name |
first_name | string | Traveller’s first name |
dob | YYYY-MM-DD | Date of birth |
nationality | 2 letters | Country code (ISO 3166-1 alpha-2) |
gender | M or F | Gender |
docCountry | 2 letters | Passport issuing country (ISO 3166-1 alpha-2) |
docNumber | string | Passport number |
docExpireDate | YYYY-MM-DD | Passport expiry date |
home_airport | 3 letters | Nearest airport (IATA code) |
string | (Optional) Traveller’s email | |
phone | string | (Optional) Traveller’s phone |
id | string | (Optional) HR system ID for syncing |
2) Vehicle information (if applicable):
Parameter | Format | Description |
---|---|---|
name | string | Vehicle name |
flag | 2 letters | Vehicle flag |
vehicleType | string | e.g., “Vessel”, “Airplane” |
3.a) Hotels information (if applicable):
Parameter | Format | Description |
---|---|---|
location | string | Hotel location |
checkIn | YYYY-MM-DD | Check-in date |
checkOut | YYYY-MM-DD | Check-out date |
3.b) Flights information (if applicable):
Parameter | Format | Description |
---|---|---|
origin | 3 letters | Departure airport (IATA) |
destination | 3 letters | Final destination (IATA) |
date | YYYY-MM-DD | Final departure date |
Intermediate Stops (if any):
Parameter | Format | Description |
---|---|---|
destination | 3 letters | Stopover airport (IATA) |
date | YYYY-MM-DD | Departure date from that airport |
Performance Requirement
Your API response time must stay below 3 seconds to ensure a smooth user experience.
Option 2.2 Upload your data via our REST API
Example of request to our API for marine sector
POST https://integrations.cteleport.com/travelers-requests
Header: X-Api-Key: [your API key]
Body:
[
{
"externalInfo": {
"requestId": "TR123", //Your id of the main entity which helps users to identify this entity on our UI"
"subRequestId": "SUBREQ123", //optional
"additionalInfo": { //filters
"AMS-RIX_departure_time": "08:00", //in local timezone of the airport
"AMS-RIX_flight_id": "your flight_id for this leg",
"RIX-JFK_departure_time": "08:00", //in local timezone of the airport
"RIX-JFK_flight_id": "your flight_id for this leg"
}
},
"flight": {
"origin": "AMS",
"destination": "JFK",
"date": "2025-06-01",
"intermediateAirports": [
{
"airport": "RIX",
"date": "2025-05-30"
}
]
},
"details": {
"vehicle": {
"name": "Vessel One",
"flag": "NL",
"vehicleType": "Vessel"
}
},
"traveler": {
"id": "231", // Id of the traveler in your system, if we need it for delivering of data
"lastName": "Smithsen",
"firstName": "John",
"dob": "1978-12-03",
"nationality": "GB",
"gender": "M",
"docCountry": "GB",
"docNumber": "UK36276372323",
"docExpireDate": "2025-04-30",
"email": "test@test.nl",
"phone": "+3167212121"
}
}
]
You can send us preliminary information about upcoming travels through the REST API using your API key, and it will instantly become available in your C Teleport interface for tickets booking. If you want, you can conduct a test of this integration within our dedicated development environment, giving you the opportunity to perform a thorough verification before proceeding to the production stage.
Also you can delete your Travel Requests
DELETE https://integrations.cteleport.com/travelers-requests?requestId=123&subRequestId=1234
Header: X-Api-Key: [your API key]
3. Crew change integration
Example of request to your webservice
GET http://yourcompany.com/api/crew_change?date=2017-06-03
Example response in case of marine sector
[
{
"vessel": "CMA CGM Passat",
"flag": "GB",
"onsigners": [
{
"id": "231",
"last_name": "Smithsen",
"first_name": "John",
"dob": "1978-12-03",
"nationality": "GB",
"gender": "M",
"doc_country": "GB",
"doc_number": "UK36276372323",
"doc_expire": "2019-04-22",
"home_airport": "LON",
"email": "smithsen@gmail.com",
"arrive": "2017-06-03"
}
],
"offsigners": [
{
"id": "4343",
"last_name": "Petrov",
"first_name": "Sergey",
"dob": "1965-11-22",
"nationality": "RU",
"gender": "M",
"doc_country": "RU",
"doc_number": "RU3627362332",
"doc_expire": "2019-08-11",
"home_airport": "LED",
"email": "petrov@mail.ru",
"depart": "2017-06-03"
},
]
}
]
Through the crew change integration, C Teleport can access your crew planning data and automatically populate the information when you search for a flight. While this integration can be applied across various sectors, the specific data requirements for the integration may differ depending on the particular industry in question.
For example, in marine sector, when users enter a vessel and a date for a crew change, C Teleport will pre-fill all airports and Traveller data as showed below.
This is the desired workflow:
Option 3.1 Your API or webservice
You have to expose an API.
C Teleport will be sending a GET
request to your webservice with a date entered by a user.
Based on the date, your webservice prepares the crew change data, lined up for this date.
Required data for crew change integration in the marine sector
Your webservice has to collect 3 pieces of data: 1. vessels data, which have crew changes on the requested date 2. data on on-signers on the requested date 3. data on off-signers on the requested date
Parameter | Format | Description |
---|---|---|
last_name | string | Last name |
first_name | string | First name |
dob | YYYY-MM-DD | Date of birth |
nationality | 2 letters | Nationality. 2-letter country code. Standard ISO-3166-1 alpha-2. |
gender | M or F | Gender |
doc_country | 2 letters | Passport issuance country. 2-letter country code. Standard ISO-3166-1 alpha-2. |
doc_number | string | Passport number |
doc_expire | YYYY-MM-DD | Passport expiry date |
home_airport | 3 letters | IATA code of the closest airport for the Traveller. |
string | Optional. Email of the Traveller | |
phone | string | Optional. Phone of the Traveller |
id | string | Optional. ID number in HR software of Traveller for backwards synchronisation |
vessel | string | vessel name (specific to marine sector) |
flag | 2 letters | vessel flag (specific to marine sector) |
depart, arrive | YYYY-MM-DD | date of departure or arrival form/to the airport of crew change |
Option 3.2 Initiate search from your software
Example HTML form in marine sector
<form action="https://app.cteleport.com/integrations/search" method="POST">
<input type="hidden" name="vessel" value="CMA CGM Passat">
<input type="hidden" name="flag" value="GB">
<input type="hidden" name="change_airport" value="AMS">
<input type="hidden" name="onsigners[0][arrive]" value="2017-06-03">
<input type="hidden" name="onsigners[0][last_name]" value="Smithsen">
<input type="hidden" name="onsigners[0][first_name]" value="John">
<input type="hidden" name="onsigners[0][dob]" value="1978-12-03">
<input type="hidden" name="onsigners[0][nationality]" value="GB">
<input type="hidden" name="onsigners[0][gender]" value="M">
<input type="hidden" name="onsigners[0][doc_country]" value="GB">
<input type="hidden" name="onsigners[0][doc_number]" value="UK3627637">
<input type="hidden" name="onsigners[0][doc_expire]" value="2019-04-22">
<input type="hidden" name="onsigners[0][home_airport]" value="LON">
<input type="hidden" name="onsigners[0][email]" value="smithsen@gmail.com">
<input type="hidden" name="onsigners[0][id]" value="your_software_id_3262">
<input type="hidden" name="onsigners[0][custom_fields][any_name]" value="The field value">
<input type="hidden" name="onsigners[1][arrive]" value="2017-06-03">
<input type="hidden" name="onsigners[1][last_name]" value="Smith">
<input type="hidden" name="onsigners[1][first_name]" value="Peter">
<input type="hidden" name="onsigners[1][dob]" value="1968-06-15">
<input type="hidden" name="onsigners[1][nationality]" value="DK">
<input type="hidden" name="onsigners[1][gender]" value="M">
<input type="hidden" name="onsigners[1][doc_country]" value="DK">
<input type="hidden" name="onsigners[1][doc_number]" value="DK3672643">
<input type="hidden" name="onsigners[1][doc_expire]" value="2020-12-02">
<input type="hidden" name="onsigners[1][home_airport]" value="CPH">
<input type="hidden" name="onsigners[1][email]" value="smith@gmail.com">
<input type="hidden" name="onsigners[1][id]" value="your_software_id_2345">
<input type="hidden" name="onsigners[1][custom_fields][flight_request_id]" value="1234567890abc">
<input type="hidden" name="offsigners[0][arrive]" value="2017-06-03">
<input type="hidden" name="offsigners[0][last_name]" value="Petrov">
<input type="hidden" name="offsigners[0][first_name]" value="Sergey">
<input type="hidden" name="offsigners[0][dob]" value="1965-11-22">
<input type="hidden" name="offsigners[0][nationality]" value="RU">
<input type="hidden" name="offsigners[0][gender]" value="M">
<input type="hidden" name="offsigners[0][doc_country]" value="RU">
<input type="hidden" name="offsigners[0][doc_number]" value="RU3627362">
<input type="hidden" name="offsigners[0][doc_expire]" value="2019-08-11">
<input type="hidden" name="offsigners[0][home_airport]" value="MOW">
<input type="hidden" name="offsigners[0][email]" value="petrov@mail.ru">
<input type="hidden" name="offsigners[0][id]" value="your_software_id_892">
<input type="hidden" name="offsigners[0][custom_fields][flight_request_id]" value="1234567890abc">
<input type="submit" value="Search flights">
</form>
You may use POST
requests to send your users from your crewing system straight to search results in C Teleport. In this case C Teleport has no access to your crewing system and you maintain the highest level of security. However it decreases flexibility because suggestion of crew member by name is not possible.
Here is the desired workflow:
When a user lands on C Teleport webpage, he has to be authorised. If the user was previously authorised he seamlessly proceeds to the search results page.
If your crewing system is browser-based, we recommend using <form method="POST">
with hidden fields pre-filled with the required data.
Data format is the same as in crew planning by date.
Traveller name should contain letter and spaces only. All non-letter characters such as apostrophe, dot, comma and etc should be removed from the name.
In this case the user will be leaving your HR software and go to C Teleport. User will land straight on search results page. After finalizing bookings user will have to go back to your HR software. You may also choose to send the booked tickets back to your HR software. In this case you need to have additional syncing integration.
Option 3.3 Upload your data via our REST API
Example of request to our API for marine sector
POST https://integrations.cteleport.com/travel-requests
Header: X-Api-Key: [your API key]
Body:
[
{
"travel_request_id": "TR12345", // Optional back-sync ID
"vessel": "Sample Vessel", // Vessel name
"flag": "NL", // Vessel flag, 2-char ISO code
"change_date": "2023-08-10", // YYYY-MM-DD format
"onsigners": [
{
"id": "S123",
"last_name": "Doe",
"first_name": "John",
"dob": "1990-01-15", // YYYY-MM-DD format
"nationality": "NL", // 2-char ISO code
"gender": "M", // 1 letter
"doc_country": "NL", // 2-char ISO code
"doc_number": "ABC123",
"doc_expire": "2025-01-15", // YYYY-MM-DD format
"home_airport": "AMS", // IATA-code of the home airport
"email": "john.doe@example.com", // Optional
"phone": "1234567890", // Optional
"metadata": { // Additional information for sending to third-parties systems
"key1": "value1",
"key2": "value2"
},
"change_date": "2023-08-10" // YYYY-MM-DD format
}
],
"offsigners": [
{
"id": "S125",
"last_name": "Williams",
"first_name": "Michael",
"dob": "1992-03-05", // YYYY-MM-DD format
"nationality": "GB", // 2-char ISO code
"gender": "M", // 1 letter
"doc_country": "GB", // 2-char ISO code
"doc_number": "DEF456",
"doc_expire": "2025-03-05", // YYYY-MM-DD format
"home_airport": "LHR", // IATA-code of the home airport
"email": "michael.williams@example.com", // Optional
"phone": "4433221122", // Optional
"metadata": { // Additional information for sending to third-parties systems
"key5": "value5",
"key6": "value6"
},
"change_date": "2023-08-10" // YYYY-MM-DD format
}
]
}
]
You can send us preliminary information about upcoming crew changes through the REST API using your API key, and it will instantly become available in your C Teleport interface for tickets booking. If you want, you can conduct a test of this integration within our dedicated development environment, giving you the opportunity to perform a thorough verification before proceeding to the production stage.
4. Reverse integration
Example payload
{
"actions":
[
{
"action": "confirmed",
"timestamp": 1514925900,
"user": "email@yourcompany.com"
},
{
"action": "cancelled",
"timestamp": 1514925950,
"user": "email@yourcompany.com" // email or "c teleport bot" keyword
}
],
"passenger": {
"last_name": "Timze",
"first_name": "Oskars",
"id": "crew-2323" // Id received from your software through integrations in article 2
},
"durations": [455],
"segments": [
{
"carrier": "KL",
"flight_number": "3092",
"origin": "RIX",
"destination": "AMS",
"departure_date": "2018-01-02",
"departure_time": "16:25",
"connecting": true,
"arrival_date": "2018-01-02",
"arrival_time": "17:50",
"cabin_class": "Economy"
},
{
"carrier": "KL",
"flight_number": "1097",
"origin": "AMS",
"destination": "MAN",
"departure_date": "2018-01-02",
"departure_time": "21:45",
"arrival_date": "2018-01-02",
"arrival_time": "22:00",
"destination_terminal": "3",
"connecting": false,
"cabin_class": "Economy"
}
]
,
"baggage": {
"RIX-MAN": {
"checked": {
"pcs": 2,
"weight": 23,
"url": "MYTRIPANDMORE.COM/BAGGAGEDETAILSKL.BAGG"
}
}
},
"tickets": ["0745267507710"], // Can be multiple tickets
"id": "285e3b89ee3846a5a6e035d4794939a8",
"locator": "C-DRF2P8",
"terms": {
"fare_type": "public",
"splitting": false,
"cancellations": "refundable",
"changes": "paid-change"
},
"metadata": { // in metadata can be added any other field that you required
"crew_change_member": "JOHN",
"crew_change_airport": "MAN",
"crew_change_date": "2018-01-02"
},
"state": "issued", // values: confirmed / issued / refund_pending / cancelled / approval_required / declined / change_pending
"price": {
"total": 463.98,
"ccy": "EUR"
},
"created_at": 1513865074,
"created_by": {
"name": "Adam Smith",
"email": "smitrh@company.com"
},
}
When a user takes any action related to a booking, C Teleport can send this data to your crewing system. Specifically, when a user books a flight, your software will receive all the details that you need regarding the flight (itinerary, traveller, baggage allowance, price...). In case a user changes the flight booked, your software will promptly be updated with the new flight information. On the other hand, if a user decides to cancel a flight, your software will reflect the change by indicating that there is no longer a booking. This process ensures that your HR software stays always synchronized with C Teleport.
You can choose between “push” or “pull” approach. With the "push" approach, you need to provide an API through which C Teleport can push booking data to your system in real-time. If you don't have any API and you don’t want to develop it for some reason, you may choose to pull this data from C Teleport API endpoints.
You will be notified of all states of your booking and corresponding ticket(s).
Here are the states that we deliver to your system by default.
Description of payload
Payload sent with push/pull request will consist of a set of actions performed by user or system and a complete snapshot of the booking after this action.
Section | Purpose |
---|---|
actions | Array of actions related to your booking. There will be always only 1 action if you are using pushing approach. There can be multiple actions if you are pulling, because we will accumulate actions between current and the previous pull call. |
passenger | Traveller data for double-checking together with the traveller's ID, which we received from your software through integrations in article 2. |
durations | Durations of all flights (segments) in the booking in minutes. |
segments | Detailed information on each flight (segment) in the booking. |
baggage | Baggage allowances. |
tickets | List of issued tickets. Can be empty if tickets are not issue yet. |
id | ID used to identify the booking in C Teleport. Can be used to build URLs to C Teleport. For example, to open a booking screen. |
locator | User-friendly identifier of the booking. Used by support team to identify and find bookings. |
terms | Contains data on terms of the ticket: is it marine or public ticket, is it single or split-ticket (consists of two reservations) and information about possibility of changing and canceling. |
metadata | Data on crew change and direction of the flight: off- or on-signing. |
state | Current state of the booking: confirmed , issued , refund_pending , cancelled , approval_required , declined , change_pending . |
price | Data on price and currency. |
created_at | Timestamp of creating the booking. |
created_by | Details on the user, who created the booking |
Option 4.1. C Teleport pushes data to you
Example of request
POST https://yourcompany.com/api/sync_flights
In this scenario, C Teleport will transmit the required data to your API endpoint (an example of the payload is provided above). You have to expose the API endpoint and process the received data.
Please tell us the endpoint address as well as security information.
When a user takes an action that that the status of a booking or ticket, C Teleport will initiate an API call to your system. You will need to handle the data payload received during this call.
Option 4.2. You pull data from C Teleport
Example of request
GET https://integrations.cteleport.com/bookings
Header: X-Api-Key: [your API key]
When you want to maintain top level of security, you may pull the data about flights from C Teleport instead of pushing it. In this way your system remains completely closed, but you still can sync the flights data.
Under this scenario you will call our API endpoint https://integrations.cteleport.com/bookings
. This endpoint will accumulate all changes that you didn't collect since your last call. Therefore, you will be receiving an array of bookings with arrays of actions performed with the bookings.
Please mind that unlike PUSH, this method will not provide real-time synchronisation between C Teleport and your system.
Other methods for data exchange
While we strongly recommend HTTP GET/POST
data exchange methods with JSON
payload, we also understand that some systems may not support it. Therefore, we accept virtually any other methods of communication, incl.:
- non JSON file types
- XML, SOAP
- CSV
- YAML
- others
- Non HTTP data exchange
- FTP file transfer
- SSL file transfer
- E-mail file transfer
Please remember that we can develop a secure and stable webservice for you even if your current software does not support it. Please contact us if you need help.
FAQ
Data from our crewing software doesn't have the same format as described in this document. What shall we do?
For each new integration we conduct an analysis to identify the disparities and, if necessary, transform data to match the desired format.
We need to have specific data that is not mentioned in this document, is it possible to handle it?
Yes, we always analyze your needs and specific requirements to ensure comprehensive data coverage.
Is the comunication between our system and C Teleport secure?
We recommend communications over HTTPS, which will be protected by the SSL certificate. It is virtually impossible to break it. In case of doubts, ask us any questions about security.
How long does it take to integrate?
The time required for integration may vary depending on the complexity, but in our experience, the development phase alone can be accomplished in just a few hours.
Is it possible to test the integration in an environment different than production?
Yes, we can set up our development environment to accommodate your testing requirements. We will provide you all the information needed to perform the tests in complete autonomy.