What a connector does
- Reads obligations, payments and ledger entries from the accounting system.
- Maps them onto Pey's canonical model — which is where the real work is.
- Emits events back when Pey has something to say, for that system to book.
The third step is the constraint that shapes everything: a connector never posts. It hands the accounting system an event and the accounting system decides what entry to make. See the rule.
The connectors
| System | State | Notes |
|---|---|---|
| erp.io Accounting | First | Reads the module API with an organisation-scoped key. |
| QuickBooks | Planned | Against the same canonical model. |
| Xero | Planned | Against the same canonical model. |
| Others | Later | The contract is designed to make each one smaller than the last. |
Connecting to our own accounting module first is convenient, and the risk of convenience is that the contract quietly assumes things only our module does. The canonical model is deliberately unlike any one system's schema for exactly that reason — if the second connector is hard, the first one was written wrong.
Authentication
A connector authenticates to the accounting system as an integration, with an organisation-scoped API key — the same kind of key documented in Authentication. It acts for one organisation, and it is revocable from that organisation's settings without touching anything else.
Pey keeps its own database, separate from any ledger it connects to. Sharing one would quietly undo the decision to keep them separate — and would make the portability claim untrue the moment anybody looked.
What this does not do
The others are planned, not partially built.
Events, never postings.
Pey reads what the ledger has; it is not a second bank feed.
Deliberately.
Questions
Can we connect two accounting systems?
That is the eventual point of a payment graph. Not yet.
Does the connector need write access?
It emits events. It does not post entries.
Where does the data live?
In Pey's own database.