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

# Interfaces

> How canonical events and state reach the systems you already run.

REM Sync delivers canonical financial events and state into existing systems. REM integrates these systems; it does not replace them.

<Info>
  REM does not publish a public, self-serve API. Interfaces are configured per deployment against the destination systems in scope, and their schemas are versioned with the canonical model.
</Info>

## Delivery interfaces

| Interface                             | Use it for                                                                             |
| :------------------------------------ | :------------------------------------------------------------------------------------- |
| **REST / OpenAPI**                    | Querying canonical state, lifecycle status, and reconciliation results                 |
| **Webhooks**                          | Pushing lifecycle events (for example, a deposit becoming creditable) to your services |
| **Kafka-compatible streams**          | High-volume event delivery with replay into your own event backbone                    |
| **PostgreSQL and customer databases** | Materialized state written directly into tables you own                                |
| **Warehouse sinks**                   | Snowflake and similar warehouses, where reporting requires them                        |
| **Secure file exchange**              | Batch delivery for systems that only accept files                                      |

## Enterprise connectors

REM connects to the systems around the ledger, as each engagement requires:

* ERP and accounting systems;
* custody and wallet providers;
* treasury and bank systems;
* compliance providers (KYC, KYT, sanctions, Travel Rule), as inputs to a workflow; and
* internal ledgers and books of record.

ISO 20022 and FIX are supported only for a validated workflow that needs them.

## Delivery guarantees

* **At-least-once ingestion, exactly-once business effects.** Every delivery carries stable event identifiers so consumers can apply idempotently. Replays and retries do not double-credit.
* **Finality-aware.** Events carry their finality and correction state. Consumers can choose to act only on finalised events, and corrections are delivered as first-class events.
* **Traceable.** Every delivered event links back to its raw source record and forward to every action taken on it.
* **Versioned.** Schemas, mappings, and policies are versioned, and a change never silently rewrites history.