Everything you need to run AirlineDB

Introduction

Travel agents live and die by policy detail: how many days before departure a name correction is free, which fare brands allow same-day changes, whether an interline agreement covers a missed connection. That information is scattered across airline agent portals, PDFs, and institutional memory. AirlineDB gives an agency one searchable, always-reviewed place to keep it — organized by airline, versioned like a wiki, and backed by AI that drafts updates from real airline sources without ever publishing anything unreviewed.

Under the hood it's a custom Django application (no off-the-shelf CMS), built specifically around two things generic wikis don't do well: strict isolation between travel agencies sharing one server, and a two-tier content model where a platform-wide "master" set of airline data flows down into each agency's own knowledge base.

Who it's for

AirlineDB is built to be run by one operator — a host, or a lead agency — for a number of independent travel agencies:

Agencies & multi-tenancy

Every piece of agency-facing content in AirlineDB belongs to exactly one agency. Agencies are fully isolated from one another — a user at one agency can never read, search, or export another agency's knowledge base, even though both are served from the same install. Each agency has its own users, its own copy of every airline and ticketing article, its own tags and notes, and its own light/dark accent color.

Above the agency layer sits Server Staff, a tier with no agency of its own. Staff curate the shared master content and server-wide settings but don't see into any individual agency's private notes or tags.

Master vs. agency content

AirlineDB keeps two parallel master lists maintained by Server Staff:

• The master airline list — one canonical record per airline (fleet, alliance, fare brands, reference info, and MasterAirlineArticle policy write-ups grouped into ten categories, including Name Corrections).
• The master ticketing list — shared ticketing rules and processes that aren't airline-specific.

When an agency links to a master airline, flat fields (fleet, alliance, fare brands, and so on) sync automatically. Longer MasterAirlineArticle content — the actual policy write-ups — works differently: an agency pulls it in explicitly from a self-service picker (Add to my KB / Update / Up to date), so nothing lands in an agency's wiki without someone there choosing it.

Roles & permissions

Permissions are set in two layers. A Server Permission ceiling, set once by the Super Admin, defines the maximum any role is allowed to do. An Agency Permission can then narrow that ceiling further for a specific agency — it can only take permissions away, never grant more than the ceiling allows.

Permission keys are registry-driven rather than hardcoded — for example edit_airline_kb, edit_ticketing_kb, manage_permissions, and review_content_updates (which controls who can act on the Content Updates approval queue). This is what lets a permission be extended to a new role, like giving Managers approval rights, without a schema change.

Airline Wiki

Feature

The core of AirlineDB is a Markdown wiki, one page per airline, with full revision history. Creating an airline can autofill reference data from Wikipedia, Wikidata, and OpenFlights — the fetched data is always staged for review before it's saved, never written silently. Articles support colored tags, source-citation bubbles that link a fact back to where it came from, and a fleet field alongside richer profile data (airline type, subsidiaries and regional partners with IATA hints, fare brands and fare families per cabin, points of sale by region, GSA relationships).

Policy write-ups render inline on the airline's page — grouped by category, with the rendered Markdown, a source citation, and an edit shortcut right there — rather than as a bare link out to a separate article view.

Ticketing knowledge base

Feature

A parallel knowledge base for ticketing processes and rules that live outside any one airline's profile — refund workflows, interline ticketing, and similar cross-airline procedures. It follows the same editing and permission model as the Airline Wiki, gated by its own edit_ticketing_kb permission.

Content Sources & AI drafting

Feature

Content Sources is how AirlineDB keeps the master lists current without a human re-reading every airline portal by hand. A Server Staff member registers a source URL — an airline agent portal page, say — and a background checker fetches it, diffs it against the last known version by content hash, and, on a real change, asks the configured AI model to map the page onto a fixed field schema and propose one or more category articles.

Nothing from a source is ever written automatically. Every AI pass produces a SuggestedUpdate that sits pending until a Staff member reviews it field-by-field and article-by-article and applies or dismisses it.

The scraper handles modern airline portals, including single-page apps that render their content client-side: it detects an unrendered JS shell and automatically falls back to a headless-browser fetch. Fetching itself is SSRF-guarded — it refuses to resolve to non-public IP ranges — and restricted to Staff and Super Admin.

AI providers

AI Settings is multi-provider: Anthropic, OpenAI, Google, or any OpenAI-compatible endpoint, including a locally-hosted model through Ollama. The API key is never redisplayed once saved, and leaving the key field blank on save keeps the existing one.

Approval workflow

Feature

AI-sourced master article updates don't sync straight into an agency's knowledge base. Instead they raise an AgencySyncRequest that lands in that agency's Content Updates inbox, where an Admin (or a Manager granted review_content_updates) approves or dismisses it. Staff's own manual edits to the master list are treated differently — those still sync out instantly, since a human at the source has already reviewed them.

Theming

Feature

Every agency picks its own accent color, tinting both the light and dark variants of its pages and top bar. Server Staff, who don't belong to an agency, get a personal theme picker instead of an agency one. Theme controls live in the account menu rather than the main sidebar.

Import, export & server data

Feature

Each agency can import and export its own knowledge base as CSV. Above that, a Super-Admin-only Server Data hub covers platform-level movement of data: server settings, subscription tiers, and full per-agency JSON bundles (profile, tags, airlines, categories, articles, ticketing) that can be exported and re-imported using natural-key relations, so a bundle from one server can be dropped into another and updates apply in place rather than duplicating records. API keys are deliberately excluded from every export.

Getting started

Admin guide

1. Log in as Super Admin and create your first agency from the Agencies screen — this also creates that agency's initial Admin account.
2. Set an accent color and, if you have one, a logo for the agency under Agency Settings.
3. Populate the master airline list for the carriers your agencies book most — autofill from Wikipedia/Wikidata/OpenFlights gets the reference fields most of the way there.
4. From within the agency, link its profile to the relevant master airlines, then use Add to my KB on each one to pull in the published policy articles you want visible.
5. Invite the rest of the agency's users; new sign-ups land in an approval queue rather than getting instant access.

Setting up AI Content Sources

Admin guide

1. Go to AI Settings (Staff / Super Admin only) and choose a provider — Anthropic, OpenAI, Google, or an OpenAI-compatible base URL for a local model.
2. Paste in an API key (skip this for a local, keyless endpoint) and save. The status indicator confirms the provider is reachable.
3. Add a Content Source: the URL of an airline policy or reference page. Prefer a single policy page over a broad links hub — a hub page often summarizes without giving the AI concrete fields to extract.
4. Run the source checker (or wait for the scheduled check_content_sources pass) and review what lands in the Suggested Updates queue before applying anything.

Managing permissions

Admin guide

Permissions are split across three screens, matching the ceiling/narrowing model:

Server data & backups

Admin guide

Use the Server Data hub before any major change — a platform upgrade, a bulk master-list edit — to export a snapshot of server settings and every agency's bundle. Re-importing a bundle updates matching records in place rather than duplicating them, which makes it safe to use for moving an agency between servers, not only for restoring from a backup.

FAQ

Recent changelog

Highlights from recent development — see the project history for the full build log.