Reviewed the December 2025 OpenEDC API email guidance and the existing OpenEDC Supabase integration in mono/apps/vxdata-jobs.
Found that the Confimedis web app exposes its public Supabase URL and anonymous key through https://cloud.confimedis.com/api/status.
Added a small local smoke-test script at ~/work/playground/openedc/check_openedc.py. It reads only the public connection config, signs in with email and password from environment variables, and prints ok.
Ran the script through op run --env-file using secret references to the supplied 1Password item. Authentication succeeded. No OpenEDC tables, storage objects, or clinical records were queried.
Lessons Learned: Pitfalls
The requested shorthand path ~/work/mono/vxdata-jobs maps to ~/work/mono/apps/vxdata-jobs in the current monorepo. The requested @openedc/ files were instead under ~/work/playground/openedc/.
The existing OpenEDC client accepts browser-extracted access and refresh tokens. That path is unsuitable for durable automation because those tokens expire quickly.
Lessons Learned: Improvements
Future OpenEDC jobs can authenticate with sign_in_with_password and obtain fresh sessions from durable user credentials.
The public /api/status endpoint removes the need to copy or store the Supabase anonymous key. Secrets should remain 1Password references and be injected only into the process with op run.
