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

# Integration

> Five touchpoints, the same for every book: onboard, submit obligations, sign once, act on each run, reconcile. Coming soon.

<Note>
  **Coming soon.** Multilateral Netting opens to design partners first. Paths, field names, and schemas below are the planned shape; final versions publish at launch.
</Note>

* **Five touchpoints, the same for every book** - agent usage, loans, invoices, trades.
* **You never call a clearing contract to submit or settle** - you sign once, and the protocol can use that signature only inside your window and only for your net.
* **The run itself:** [How It Works](/netting/how-it-works).

| # | Touchpoint | What you do | Surface |
| - | - | - | - |
| 1 | [Onboard](#onboard) | Hold the membership credentials, set your policy domain | Console or service-account API |
| 2 | [Submit obligations](#submit-obligations) | Bring debts in: cleared quotes, signed debts, or batches | RFQ `mode: cleared`, `POST /clearing/obligations`, `POST /clearing/batches` |
| 3 | [Sign once](#sign-once) | One envelope authorizes a lock of your net, inside a window | Permit2 or ERC-3009 |
| 4 | [Each run](#each-run) | Read your notice, object or stay silent, your net locks | `notice.published`, `POST /clearing/objections` |
| 5 | [Reconcile](#reconcile) | Map your gross book to what moved | `GET /clearing/runs/{id}/statement` |

## Onboard

* **Workspace and API key** - as for any TetraFi API ([Authentication](/core-concepts/authentication)).
* **Credentials admit you** - a verified legal entity, sanctions-clear standing, rulebook adherence, and one completed test run. Nobody hand-picks applicants.
* **Set your policy domain** - who you net with (each pair approves the other), your deadline-tier menu, and your visibility slice.

**Key fields:** legal entity, credentials held, counterparty sets, deadline tiers.

## Submit Obligations

An obligation is **one debt**: who owes whom, how much, in which asset on which chain, by when. Three ways in, set by who asserts the debt:

| Route | Use it for | How |
| - | - | - |
| **Cleared quote** | Trades on TetraFi's rails | `mode: cleared` plus a deadline tier on the [RFQ quote request](/rfq-api/introduction) |
| **Signed debt** | A debt you owe - a repayment, a payout, a corridor payment | `POST /clearing/obligations`, signed by you; your creditor sees it inside a notice window |
| **Batch of claims** | Debts owed to you, or usage your platform records | `POST /clearing/batches`; each debtor approves its own lines, and unapproved lines expire |

**No edit path** for trade-born obligations: a correction is a signed offsetting entry, never an amendment.

**Key fields:** counterparty, asset and chain, amount, deadline, and an `Idempotency-Key` header on every write.

## Sign Once

* **One EIP-712 signature per obligation carries everything** - the debt, where its funding comes from, the window it may be locked in, a lock limit bound to the run, and the compliance policy it was accepted under.
* **Enforced on-chain** - it travels as a Permit2 witness or inside an ERC-3009 authorization, so the window is enforced at lock time.
* **Any custody stack** that signs EIP-712 typed data can produce it.
* **Signing is off-chain** - beyond a one-time [Permit2 approval](/core-concepts/token-approvals) per token, you never call a clearing contract to submit or settle.

**Key fields:** obligation, funding sources, window (`notBefore`, `notAfter`), lock limit, compliance policy hash.

## Each Run

Runs follow your deadlines. For each one:

<Steps>
  <Step title="Notice">
    A `notice.published` event brings **your net per asset and chain** - arithmetic over debts you already signed.
  </Step>

  <Step title="Object or stay silent">
    `POST /clearing/objections` names obligation ids inside the notice window. **Silence accepts.**
  </Step>

  <Step title="Lock">
    When the lock window opens, your signature locks **your net - never more** - into your own escrow position for that run. Until then your capital stays in your wallet.
  </Step>

  <Step title="Commit and release">
    When the lock window closes, the run commits over everything that locked and balances, and **pays out only along obligations you signed**. A side that didn't lock drops out with whatever depended on it, is refunded, and carries to the next run - nothing is recomputed.
  </Step>
</Steps>

**Late counterparty on a paired trade?** `POST /clearing/resolutions` records your choice: accept a buy-in bid from the auction or the vault, wait, or declare.

**Key fields:** run id, net per asset and chain, notice window, lock window.

## Reconcile

* **One statement per run** - every obligation it touched (signed, set off, remaining) with its lock, release, refund, and fee lines: your gross book mapped to the net that moved.
* **ISO 20022 exports** - camt.053 for the statement, pacs.009 for each released net.
* **Provably the agreed copy** - the statement's hash is committed on-chain.

**Surface:** `GET /clearing/runs/{id}/statement` and `settlement.released` events.

## How a Debt Ends

| Ending | What happens |
| - | - |
| **Settled in a run** | Set off, released, or both - final at commit |
| **Settled outside, with proof** | You paid another way; both signatures, a custody balance change, or a proven receipt closes it |
| **Torn up** | Both parties sign it away - nobody cancels a debt alone |
| **Late** | The resolution ladder prices it out: standby funding, a discount auction, vault liquidity, the wholesale desk, or external settlement |

## Endpoint and Event Map

| Planned endpoint | Purpose |
| - | - |
| `POST /clearing/obligations` | Submit a signed debt |
| `POST /clearing/batches` | Submit claims or platform usage; `mode: analyze` returns what would net and executes nothing |
| `GET /clearing/obligations` | Your obligations: signed, set off, remaining |
| `GET /clearing/positions` | Your net per asset and chain |
| `GET /clearing/notices` | Notices, also pushed to your webhook |
| `POST /clearing/objections` | Object inside the notice window |
| `POST /clearing/resolutions` | Your election when a paired counterparty is late |
| `GET /clearing/runs/{id}/statement` | The run statement |
| `POST /clearing/payout-instructions` | Pay a residual out to the asset and chain you choose |

Events, pushed to the webhook you register: `batch.analyzed`, `notice.published`, `run.committed`, `settlement.released`, `obligation.late`, `payout.settled`.

## On-Chain

* **Clearing record** - every obligation and its state, encrypted so each member reads only its own
* **Verifier** - checks each run's validity proof before anything commits
* **Run escrow** - one position per payer per run; it pays only along obligations that payer signed and refunds to the payer after a timeout, which anyone can trigger - no key of ours can send funds anywhere else
* **Settlement endpoints** - one per chain, where net movements land

You never call them to submit or settle; the protocol exercises your signature inside your window.

<CardGroup cols={2}>
  <Card title="Agentic Netting" icon="robot" href="/netting-api/agentic-netting">
    What an agent platform adds: batches from your stack, analysis mode, payouts.
  </Card>

  <Card title="Register Interest" icon="sparkles" href="/support">
    Join the design partners integrating first.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.