Connecting a Feed Provider

Feeds bring transactions in from outside. Accounting packages and bank connections are sources; the ledger is where the record lives.

What ships, and in what state

Adapters are provided for the major accounting packages and bank connections. Every one of them ships disabled and without credentials, in keeping with the platform-wide rule that nothing starts talking to an external service because somebody applied an update. You enable the ones you want and supply your own credentials.

Setting one up

1. Enable the provider you need and enter its credentials. The provider row follows the same shape as the platform's other external connections, so it will look familiar if you have configured a login method or a mail relay.
2. Create a connection binding that provider to a specific entity and a specific ledger bank account. This is what tells the system whose books an incoming transaction belongs to.
3. Test, and confirm transactions land in the inbox rather than posting straight through.

One connection per account

Resist pointing several bank accounts at one connection. The connection is what resolves which ledger account a transaction hits, and sharing one across accounts means the resolution has to be inferred from the transaction, which is exactly the kind of guess that produces a misposted month.

Webhook receipts, including failures

Every webhook received is recorded — including ones that failed signature verification. That is deliberate. A rejected delivery is not simply noise: a run of them means either a misconfigured credential or somebody probing the endpoint, and neither is visible if failures are silently discarded.

Check this log when a provider insists it has sent something you cannot find.

Credentials

Feed credentials permit reading your financial data. Treat them like any other production secret: give the connection its own credentials rather than reusing a person's login, so access can be revoked when somebody leaves without breaking the feed.