> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> The corporate-card object model at a glance: the partner → company → employee structure, the core objects and ID conventions that run through every endpoint, and the reading path across the concept pages.

## 📄 Guide

The concepts below decide how you model accounts, funds and controls for your customers. This page gives you the object landscape and the ID conventions; each concept page then follows one thread in depth.

## The three-tier identity model

Your business is organized as partner → company → employee: the partner is you (one API integration); a company is your business customer (KYB onboarding, funding pool); an employee is the end cardholder (issued cards after KYC). Cards can be issued to a company (a custodian is required) or to an employee.

<Frame>
  <img className="block dark:hidden" src="https://mintcdn.com/dcs-0bf7a937/oUoeUKtwWWK2o-Li/imgs/en/diagrams/corp-identity-model-light.svg?fit=max&auto=format&n=oUoeUKtwWWK2o-Li&q=85&s=c2fec422dbd043147079609737ceac24" alt="Partner, company, employee and card object model" width="674" height="244" data-path="imgs/en/diagrams/corp-identity-model-light.svg" />

  <img className="hidden dark:block" src="https://mintcdn.com/dcs-0bf7a937/oUoeUKtwWWK2o-Li/imgs/en/diagrams/corp-identity-model-dark.svg?fit=max&auto=format&n=oUoeUKtwWWK2o-Li&q=85&s=c3027bb8f953451dacfec6f09e4800bf" alt="Partner, company, employee and card object model" width="674" height="244" data-path="imgs/en/diagrams/corp-identity-model-dark.svg" />
</Frame>

## Core objects and ID conventions

Every ID in the contract is a JSON string, shaped as follows:

| Object                                    | ID                                                                               | Shape                     | Notes                                                             |
| ----------------------------------------- | -------------------------------------------------------------------------------- | ------------------------- | ----------------------------------------------------------------- |
| Company                                   | `organizationId`                                                                 | UUID-shaped string        | Issued once KYB passes; every later endpoint uses it              |
| Employee                                  | `customerId`                                                                     | UUID-shaped string        | Issued once KYC passes                                            |
| Card / application / event                | `cardId` / `organizationApplyId`, `customerApplyId`, `cardApplyId` / `webhookId` | 19-digit snowflake string | **Transmit as strings** — numeric literals get silently truncated |
| Rule / transfer / statement / transaction | `ruleId` / `transferId` / `statementId` / `transactionId`                        | Business strings          | Pass through verbatim                                             |
| Partner-side IDs                          | `externalXxx`                                                                    | `^[A-Za-z0-9_-]+$`, ≤64   | Generated and persisted by you; they double as idempotency keys   |

The meaning of a polymorphic ID (`subjectId` / `subjectId` / `subjectId`) is determined by the type field in the same structure, never inferred from its shape.

## Two orthogonal axes

"Who holds the card" (the holder) and "which account pays" (the funding owner) are independent axes, mapped to each other by the card profile `cardProfileId` — the key to understanding card types and the fund endpoints. See [Holders and the funding model](./identity-and-funding).

## Reading path

| Concept page                                            | The question it answers                                                                                   |
| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| [Holders and the funding model](./identity-and-funding) | Who holds the card, which account pays, and how to choose between the two funding modes                   |
| [State machines and freezing](./states-and-freezing)    | How applications, companies, employees and cards move through their states, and how freezing takes effect |
| [The transaction life cycle](./transaction-lifecycle)   | A purchase's full journey from authorization hold to posting                                              |
| [Compliance and KYC](./compliance-kyb-kyc)              | What KYB / KYC review, what to do on rejection, and which details are globally unique                     |
| [Limits and statements](./limits-and-billing)           | How spend control is expressed, and which statement is final                                              |

## Next steps

* Start with the first thread of the object model: [Holders and the funding model](./identity-and-funding)
* Or go hands-on and issue your first card: [Quickstart](../getting-started/quickstart)