cast-ghl-plugin/FUTURE_DEV.md

Future Development Notes

This document tracks planned improvements, technical debt with business impact, and migration paths for features currently implemented with known limitations.

---

Upgrade: Per-location Cast API keys from MongoDB → Infisical

Current state (Option A)

Per-location Cast API keys (cast_api_key) and sender IDs (sender_id) are stored in MongoDB alongside OAuth tokens in the cast-ghl.oauth_tokens collection.

Limitation: Secret material (Cast API keys) stored in the same database as operational data. If MongoDB is compromised, all per-location Cast credentials are exposed. MongoDB auth and TLS mitigate this but do not eliminate the risk.

Target state (Option C)

Use Infisical as the secrets backend for per-location Cast API keys. Infisical is open-source, self-hostable, and provides secret versioning, audit logs, access policies, and dynamic secrets.

Migration plan

1. Deploy Infisical (self-hosted or Infisical Cloud)

• Recommended: self-host on the same Vultr instance or a dedicated secrets VM
• Create a project: cast-ghl-provider
• Create an environment: production
• Create a machine identity (service account) for the bridge service

2. Secret naming convention

Store each location's API key as a secret named:

CAST_API_KEY_<locationId>

Example: CAST_API_KEY_q5LZDBHiJ9BsY9Vge5De

3. Code changes in the bridge

• Add INFISICAL_CLIENT_ID and INFISICAL_CLIENT_SECRET env vars to config
• Add Infisical Go SDK: github.com/infisical/go-sdk
• Create internal/secrets/infisical.go — wraps the SDK with a GetLocationAPIKey(locationID) (string, error) method and an in-process cache (TTL ~60s to avoid hammering the API)
• In processOutbound: call secrets.GetLocationAPIKey(locationID) instead of reading from the token record
• The cast_api_key field in TokenRecord can be kept as a fallback during migration, then removed

4. Admin API changes

• PUT /api/admin/locations/{locationId}/config should write the API key to Infisical (not MongoDB)
• GET endpoints should read from Infisical and mask the returned value

5. Migration of existing keys

1. For each location with a cast_api_key in MongoDB, write it to Infisical via the admin API
2. Verify the bridge reads the key correctly from Infisical
3. Clear cast_api_key from MongoDB records
4. Remove the MongoDB field once fully migrated

6. MongoDB security hardening (do regardless of Infisical migration)

• Ensure MONGO_URI uses authentication: mongodb://user:pass@host:27017/cast-ghl?authSource=admin
• Enable TLS: append ?tls=true&tlsCAFile=/path/to/ca.pem to the URI
• Restrict MongoDB network access to the bridge server IP only (Vultr firewall rules)
• Enable MongoDB audit logging for the cast-ghl database

---

Other Future Items

Inbound SMS (2-way) — Cast SIM gateway webhook

• Tracked in CASA-61
• Requires Cast SIM gateway to support outbound webhooks
• Bridge handler stub already exists (PostInboundMessage in internal/ghl/api.go)
• Need to agree on Cast webhook payload format and DID → locationId mapping

Token refresh proactive scheduling

• Currently tokens are refreshed on-demand (when expired at webhook time)
• A background goroutine that refreshes tokens 1 hour before expiry would reduce latency on the first webhook after a 24-hour token lifetime