---
title: Legacy Travel API Overview
slug: legacy-fraud-apis/legacy-travel-api-overview
createdAt: 2026-03-10T14:46:46.692Z
---

::::ExpandableHeading
###

**Topic type: Concept**

:::hint{type="warning"}
**Purpose**: Legacy Travel Fraud API overview, differences, and hashing requirements. 

**Audience**: API integrators and client developers. 

**Applies to**: Legacy Travel clients implementing via API.

**Does not apply to**: Universal APIs, any other industry, or travel clients who opt for a non-API integration.
:::
::::

:::hint{type="info"}
****<font color="#386B84">**Legacy API Notice**</font>: This API is part of the Legacy Fraud API framework and is maintained for compatibility with existing implementations.

New integrations should use the **Universal Fraud APIs** instead.

The Universal Fraud APIs provide:

- A shared core transaction model
- Consistent request and response contracts
- Industry-specific extensions
- Unified documentation and onboarding
- Ongoing feature investment

Use this Legacy API documentation only if:

- You are maintaining an existing Legacy Fraud API integration.
- You have not yet completed migration to Universal Fraud APIs.
- Accertify has specifically directed your implementation to remain on the Legacy API framework.

For new implementations, start with **Universal Fraud APIs Overview**.
:::

The Travel Fraud API is intended for transactions where the purchase represents a **travel itinerary&#x20;**&#x74;hat may include multiple components (air, lodging, rental, cruise, activities, agency, insurance), in addition to the shared core event model.

## What Makes Travel Different

Travel transactions can be:

- **Future-dated** (book now, consume later)
- **Multi-component** (flight + lodging + rental + activities)
- **Third-party booked** (agency/OTA involvement)

The Travel API supports optional structures for:

- lodging reservations, guests
- car rental details
- cruise details
- activity/excursion details
- agency details
- insurance policy context

## Hashing Requirements

The Travel API follows the platform hashing rules. Fields designated as hash-required must be hashed before submission, including:

- `giftCardNumber`
- `hashedPassword`

See: **[Hashing Requirements](docId\:yuGHwVL8eOn7vCgSwPcd3)** (Constraint) and **[Accertify Hash Algorithm](docId\:rKIK1Lb6EUUWsz3sxPCe-)** (Reference).

## Field Reference

::::LinkArray{contentSource="CUSTOM"}
:::LinkArrayItem{headerType="IMAGE" headerImage="https://api.archbee.com/api/optimize/C_ua77kdJRrVi_Gd-0NCF/z8ywjFso3Y1n0uZqNKdDv-20260326-200546.png"}
[US Travel Fields](docId\:PxWQjBEj-lTczKttbO9gf)
:::
::::