Skip to main content

Documentation Index

Fetch the complete documentation index at: https://api.corpay.com/llms.txt

Use this file to discover all available pages before exploring further.

To work effectively with Fleet API, it helps to understand the core objects and how they relate to each other.

​
Customer

A Customer represents an account in the Corpay platform. This is the top-level entity that holds the commercial relationship and forms the basis for many Fleet API workflows. A customer can have its own status, can include sub-customers (e.g. fleets), and is linked to cards and transactions. Each customer has a unique customerAccountNumber, which is used to reference and manage the customer in Fleet API. In practice, this means that most operational activity in Fleet API starts with or belongs to a customer account.

​
Card

A Card represents a physical or virtual payment instrument in the Corpay platform. Cards can be linked to a driver, a vehicle, or both, depending on the use case. They also carry rules and restrictions, such as what they can be used for, and they have a status that determines whether they can currently be used. Each card is uniquely identified through its cardIdentifier, which is used to reference and manage the card in Fleet API. Cards also move through a defined lifecycle over time. For example, a card may be created, activated, blocked, unblocked, replaced, or cancelled. These status changes are important because they reflect how a card is managed throughout its lifetime and affect whether it can be used. Fleet API allows businesses to manage many of these lifecycle changes directly and to track them through webhooks. For many businesses, the card is the central object for day-to-day operations, because it connects users, vehicles, controls, and spending.

​
Transactions

A Transaction records a usage event linked to a card. This can include fuel purchases, EV charging activity, non-fuel purchases, and related billing or tax data. Transactions also contain contextual information, such as merchant or network details. Transactions are especially important for reporting, reconciliation, analytics, and customer-facing visibility into activity on the Corpay platform.

​
Master Data

Master Data provides the reference information needed to interact with the API correctly. Examples include card types, purchase categories, products, restrictions, status reasons, card groups, and regions. This data helps ensure that requests use valid values and stay aligned with the underlying platform configuration. In simple terms, master data provides the shared vocabulary that keeps integrations consistent and reliable.

​
Webhooks

Webhooks enable event-driven integrations. Instead of checking for changes continuously, businesses can subscribe to events and receive updates automatically when something happens in the Corpay platform. Examples include card creation, card status updates, and card replacement. This makes it easier to build responsive workflows and keep external systems in sync with platform activity.

​
Synchronous vs Asynchronous Operations

​
Synchronous Operations

  • Customer management
  • Card retrieval and lifecycle actions
  • Transaction queries
  • Master data retrieval
These operations return immediate HTTP responses.

​
Asynchronous Operations

  • Card ordering
  • Event notifications (via webhooks)
Asynchronous actions either:
  • Return an acknowledgement (202 Accepted)
  • Or trigger webhook callbacks once processing completes