Additional connector types -- what does your city need?

[scottconverse]

The connector framework currently ships with four canonical types:

• file_system — local/mounted file trees, recursive ingest
• manual_drop — operator-managed drop directory for one-off document sets
• rest_api — arbitrary REST endpoints (bearer / API-key / OAuth2 client-credentials / basic auth)
• odbc — SQL databases via pyodbc (fail-closed SSRF validation; DSN-only strings rejected, Server=… form required)

Update 2026-04-23: the earlier message mentioned IMAP email as part of the roadmap. That was removed from shipping scope in T3B (connector taxonomy unification). The ImapEmailConnector class still exists on disk as dormant scaffolding but is not imported into the connector registry and is not reachable from any dispatch path. It's a possible future slice, not an in-progress one.

Still on the roadmap (unscheduled):

• SMB / NFS file shares
• SharePoint / Microsoft Graph
• Additional SQL dialects (PostgreSQL-specific, MySQL-specific, MSSQL-specific beyond what generic odbc covers)
• IMAP email (moved from in-progress to roadmap-only pending demand)

Question for the community: What municipal software does your city use? What's the #1 system you'd want connected? Please include a concrete product name (e.g. "Tyler New World RMS", "NeoGov Insight", "Laserfiche") and how you'd ingest today without this tool — that context helps us prioritize.

Security note worth calling out up front: as of v1.2.0 (T6 / ENG-001), data_sources.connection_config is encrypted at rest via a Fernet envelope. Any credentials you configure for a new connector — API keys, bearer tokens, OAuth client secrets, ODBC passwords — are ciphertext in PostgreSQL, pg_dump output, and backups. Your deployment's ENCRYPTION_KEY is what unlocks them; losing it means losing credential access. Operator walkthrough: USER-MANUAL.md §B.3.2.