Skip to main content

Key Management

Secrets are the credentials — API keys, passwords, SSH private keys, and shared secrets — that grant access to your agency's eCourtDate data and integrations. Think of them like physical keys to a secure room: anyone who has them can get in, so they must be stored carefully, never shared carelessly, and replaced immediately if lost or compromised.

This page covers best practices for managing secrets across eCourtDate integrations.

API Secrets (client_id / client_secret)​

  • Store in environment variables, never in source code
  • Rotate credentials periodically via Console > APIs
  • Use separate credentials for staging and production
  • Revoke compromised credentials immediately

SSH Private Keys (SFTP)​

  • Store in ~/.ssh directory only
  • Set permissions to read-only: chmod 400 {key.pem}
  • Never commit to version control repositories
  • Never share via email or chat
  • Use separate keys per environment/server

OAuth Client Secrets​

  • Managed in your Identity Provider (Azure AD, Google, Okta, etc.)
  • Store application secrets in environment variables
  • Rotate secrets periodically per IDP documentation

Webhook Shared Secrets​

  • Max 24 characters
  • Set via environment variable (e.g., WEBHOOK_SECRET)
  • Rotate by updating in both Console and your application simultaneously
danger

Never include secrets in support tickets, log files, error messages, or documentation. If a secret is compromised, rotate it immediately.