# Funding Endpoints

> Durable inbound routes for a tenant: rail class, asset, and the relationship between funding endpoints, deposit instructions, and deposits.

Source: https://business-api-docs.youhodler.com/docs/concepts/funding-endpoints

A `FundingEndpoint` describes a route money can come **into** the platform on
behalf of a tenant. It binds a parent (enterprise or client), a rail class
(`fiat` or `crypto`), and the routing details that the platform uses to
generate deposit instructions and reconcile inbound activity.

Funding endpoints are configuration objects, not transactions. They define the
inbound surface; deposits and deposit instructions are what flow through that
surface at runtime.

> **Practical rule:** Treat a funding endpoint as the durable inbound contract for a tenant. Treat deposit instructions and deposits as the per-event artifacts produced against it.

## Mental Model

A funding endpoint answers three questions for the platform:

- **Who is funding?** — `parent` resolves to an `Enterprise` or a `Client`.
- **On which rail?** — `rail_class` is either `fiat` or `crypto`.
- **For which asset?** — the asset the endpoint accepts.

Routing details (`fiat_routing` or `crypto_routing`) carry the rail-specific
configuration the platform needs to receive funds and tag them back to the
correct tenant.

## Lifecycle

A funding endpoint moves through four lifecycle states:

- `provisioning` — the endpoint has been requested but is not yet ready to
receive funds (address generation or rail setup is in progress)
- `active` — accepting new inbound activity
- `disabled` — temporarily not accepting new inbound activity
- `retired` — terminal; no longer in use

Disabling and retirement are configuration changes; they do not affect funds
already received through prior deposit instructions.

## Relationship To Other Resources

Read the layering in this order:

1. `FundingEndpoint` — the durable inbound route for a tenant
2. `DepositInstruction` — a per-event payment instruction generated against the
endpoint (account number, memo, deposit address, etc.)
3. `Deposit` — the actual inbound event observed on the rail and attributed
back to the tenant

Multiple deposit instructions and many deposits typically share one funding
endpoint over its lifetime.

## How This Appears In The API

**Request URL — GET**
```http
GET /funding-endpoints?account_ref=client-accounts/44444444-4444-4444-8444-444444444444&rail_class=crypto
```
**Response — application/json**
```json
{
  "items": [
    {
      "id": "11111111-1111-4111-8111-111111111111",
      "account_ref": "client-accounts/44444444-4444-4444-8444-444444444444",
      "status": "active",
      "rail_class": "crypto",
      "asset": "USDC",
      "network": "ethereum",
      "crypto_routing": {
        "asset": "USDC",
        "network": "ethereum",
        "endpoint": {
          "address": "0xAbCd1234567890AbCd1234567890AbCd12345678",
          "memo": null
        }
      },
      "fiat_routing": null,
      "created_at": "2026-05-01T10:00:00Z",
      "updated_at": "2026-05-01T10:00:00Z"
    }
  ],
  "next_page_token": null
}
```