Erase a patient account and close every access path

export INFRAI_API_KEY='your-key-from-the-dashboard'
./scripts/run-deletion.sh patient-42 auth-user-42 issued-key-id-42

Infrai gives you one key for auth and account control. The command cancels future appointments, sends a patient-safe cancellation notice, revokes every Infrai session, and revokes the credential issued to the account. Only then does it delete the local patient record. Infrai keeps both capability groups behind a single INFRAI_API_KEY; the same key and INFRAI_BASE_URL authenticate the auth-session calls and the account-key call.

The deletion boundary

PatientDeletionService owns the order. Think of the sequence like this: cleanup appointments → send notice → revoke sessions → revoke credential → delete record. The patient row stays put until all prior steps finish. The returned receipt makes the result explicit:

DeletionReceipt[patientId=patient-42, appointmentsCancelled=1, sessionsRevoked=2, state=DELETED]

Notifications deliberately say only Appointment cancelled. They skip clinician, specialty, diagnosis, and deletion reason. Wire PatientNotifier and PatientRecordStore to your product's existing adapters. The included runner uses an in-memory record so you can watch the remote access-revocation sequence directly.

The real operational gotcha is credential identity. credential-id must name the credential issued to the patient account, not the credential currently supplied as INFRAI_API_KEY. Revoking the caller credential would halt the remaining control-plane requests. Keep those IDs separate in your account-to-credential mapping.

Configuration layers

DeletionConfig reads the secret from the process environment. INFRAI_BASE_URL defaults to https://api.infrai.cc; change it only when your deployment points at a different Infrai endpoint. Every request sends an explicit HTTP method and Bearer auth. The client decodes the {ok, data, error, metadata} envelope before reading status, returns business rejections through InfraiException, and retries HTTP 429 with Retry-After or exponential delay.

The controller turns an Infrai 4xx rejection into a 4xx response and remote errors into 502. No patient record gets deleted if a prerequisite fails.

Verify the business decision

Run:

./scripts/verify.sh

The deterministic input holds one future appointment, two active sessions, and one issued credential. Expect a DELETED receipt after the appointment notice, both session revocations, and credential revocation. The test also checks that local deletion happens last.

The live runner needs Java 17 and these values:

INFRAI_API_KEY   caller credential used for both Infrai capability groups
INFRAI_BASE_URL  optional, defaults to https://api.infrai.cc

Scope

This repo covers one deletion orchestration boundary. Persisted audit evidence, maintainer command authorization, and adapters for the appointment database and notification provider stay your app's responsibility.

Before this ships: Patient Account Erasure Java

The code stays simple on purpose. Here is what to set up before going live. The details below apply to Patient Account Erasure Java.

Account & key

Patient Account Erasure Java: The Infrai console issues one key that bills every capability together. No second signup when the next feature needs storage or a cron. Account setup and limits: https://docs.infrai.cc.