Check flight layover connection time
A 120-minute stop without changing terminals rates comfortable, 60 minutes above the 60-minute minimum connection time. Enter your layover and whether you switch terminals to see if the connection is comfortable, tight or risky. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Layover minutes
- 120
- Min connection minutes
- 60
- Margin minutes
- 60
- Status
- comfortable
Missed connections ruin itineraries, and the difference between a calm stroll to the next gate and a sprint often comes down to whether the scheduled layover beats the airport’s practical minimum connection time. This check flight layover connection time tool takes the duration of your stopover in minutes and a simple flag for whether you must change terminals, then rates the connection as comfortable, tight, or risky against widely used airline minimum-connection guidance. Same-terminal connections use a sixty-minute MCT; terminal changes use ninety minutes; anything thirty minutes or more above the applicable MCT is marked comfortable. Negative durations are rejected so bad data never looks like a valid risk score.
How comfortable, tight, and risky are decided
Airlines publish minimum connection times that encode how long a passenger needs, on average, to deplane, clear any terminal transfer, and board the next flight under normal operations. From those floors the classifier applies a fixed thirty-minute comfort buffer. If your layover is shorter than the MCT, status is risky and sufficient is false—you are below common guidance even before weather or delays.
If the layover meets the MCT but is still less than MCT plus thirty minutes, status is tight and sufficient is true: the connection is legally and operationally plausible for many carriers, yet leaves little slack for late inbound aircraft or long taxi times. If the layover is at least MCT plus thirty minutes, status is comfortable: you have the minimum plus a buffer many frequent flyers treat as the practical “relax and walk” threshold.
What you can do with it
Booking-flow connection warnings
Before checkout, score each multi-leg stop by layover minutes and terminal change; block or warn on risky status and highlight tight connections.
Corporate travel policy review
Batch-classify proposed itineraries and escalate any connection below the comfort band for agent or traveler approval.
Trip-planning content and widgets
Let readers enter their layover duration and terminal-change flag on a landing page and see comfortable, tight, or risky instantly.
FAQ
What minimum connection times does this tool use?
Terminal change: 90 minutes. Comfortable requires at least those floors plus 30 minutes. These are common airline-style guidance floors, not a live airport MCT database.
What is the difference between tight and comfortable?
Tight means you meet or exceed the MCT but stay under MCT plus 30 minutes. Comfortable means you have at least MCT plus 30 minutes of scheduled layover.
What counts as a terminal change?
Any stop where you must move to another terminal, or another airport, before the next flight. It raises the minimum to 90 minutes, because shuttles, repeat security checks and longer walks add time.
What does a risky rating mean?
Your layover is shorter than the minimum connection time, so you are below common guidance even before weather or delays. For example, 70 minutes with a terminal change is 20 minutes short of the 90-minute minimum.
What is the margin shown in the result?
It is your layover minus the minimum that applies. Comfort starts once the margin reaches 30 minutes, so 90 minutes in the same terminal is already comfortable; below that, but still above the minimum, the connection is tight.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/travel/layover-time-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"layover_minutes":90,"terminal_change":false}'const res = await fetch("https://api.kit.forhosting.com/travel/layover-time-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"layover_minutes": 90,
"terminal_change": false
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/travel/layover-time-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"layover_minutes": 90,
"terminal_change": false
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/travel/layover-time-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"layover_minutes":90,"terminal_change":false}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"layover_minutes":90,"terminal_change":false}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/travel/layover-time-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"layover_minutes": 90,
"terminal_change": false
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "travel.layover_time_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
How comfortable, tight, and risky are decided
This capability encodes a transparent, deterministic approximation of that guidance rather than scraping a live MCT table: sixty minutes when you stay in the same terminal, and ninety minutes when terminal_change is true because inter-terminal shuttles, security re-checks, and longer walks add time. The response also returns margin_minutes (layover minus MCT), the applied min_connection_minutes, and a short guidance sentence so clients can show a one-line explanation next to a traffic-light UI without rewriting the rules themselves.
Input contract, response fields, and error behaviour
Example: ninety minutes with no terminal change is comfortable (sixty MCT, thirty-minute margin into the comfort band). Example: seventy minutes with a terminal change is risky (ninety MCT, twenty minutes short). POST a JSON body with two required fields. layover_minutes is a non-negative finite number: the scheduled gap between inbound arrival and outbound departure, in minutes. Values may arrive as JSON numbers or numeric strings; non-finite values and empty strings fail with invalid_input naming the field. A negative layover is rejected with a clear message that connection time cannot be less than zero—those failures are not billed. terminal_change is a boolean indicating whether the passenger must change terminals (or airports) during the stop: true selects the ninety-minute MCT, false selects sixty. Boolean true and false, the numbers one and zero, and common strings such as yes, no, true, and false are accepted; other shapes fail validation. On success the body echoes layover_minutes and terminal_change, reports min_connection_minutes for the rule that was applied, margin_minutes as the signed surplus or shortfall, status as one of comfortable, tight, or risky, sufficient as a boolean equivalent to margin_minutes greater than or equal to zero, and guidance as a human-readable English sentence. Pair the labels with your own itinerary UI; this endpoint classifies duration only and does not look up live flight schedules, baggage rules, or airport maps.
Where a layover connection-time check earns its keep
Travel agencies and online booking engines surface this check when a shopper picks a multi-leg itinerary so they can warn about tight or risky stops before payment. Corporate travel desks batch-score proposed connections when building policy-compliant itineraries and flag anything below the comfort band for human review. Mobile companions for frequent flyers store preferred buffers and still call this API for a consistent three-way label against the published MCT floors.
Technical questions
How do I check if my flight layover connection time is enough?
Send layover_minutes (non-negative) and terminal_change (true if you must change terminals). The API returns status comfortable, tight, or risky against 60- or 90-minute MCT guidance plus a 30-minute comfort buffer.
What happens if layover_minutes is negative?
The task fails with invalid_input. Connection time cannot be less than zero, and invalid input is not billed.
What does the layover connection time check cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.