Paul Trowbridge
c4e7211e6d
Sources with a `teller` block in their config can pull transactions straight from the bank instead of taking a CSV upload. Only the fetch differs — dedupe, logging, and transformation reuse the import path. api/lib/teller.js speaks Teller's mutual-TLS protocol (client cert plus the access token as the HTTP Basic username) and flattens transactions into the shallow map the rule engine expects. Access tokens live in .env, one per enrollment, not in the database that manage.py offers to reset. Pending transactions are skipped by default: their ids change when they post, which would import the same charge twice under two keys. Sources should use ['id'] as constraint_fields — Teller's transaction id makes overlapping pulls free while keeping genuinely repeated charges distinct. Untested against the live API — Teller has no self-serve signup at the moment, so no account to verify against. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G2HFeU5neCKagTnmA6o9Tu
22 lines
695 B
Plaintext
22 lines
695 B
Plaintext
# Database Configuration
|
|
DB_HOST=localhost
|
|
DB_PORT=5432
|
|
DB_NAME=dataflow
|
|
DB_USER=postgres
|
|
DB_PASSWORD=your_password_here
|
|
|
|
# API Configuration
|
|
API_PORT=3000
|
|
NODE_ENV=development
|
|
|
|
# Teller (optional — only needed for API-based bank feeds)
|
|
# Client certificate + key downloaded from the Teller dashboard; every API call
|
|
# presents them (mutual TLS). Keep both outside the repo.
|
|
TELLER_CERT_PATH=/etc/dataflow/teller/certificate.pem
|
|
TELLER_KEY_PATH=/etc/dataflow/teller/private_key.pem
|
|
|
|
# One access token per enrollment, produced by Teller Connect. A source picks
|
|
# its token with config.teller.token_env; TELLER_TOKEN is the default.
|
|
TELLER_TOKEN=token_here
|
|
# TELLER_TOKEN_HUNTINGTON=token_here
|