Secure Messaging

Secure messaging is the hosted SPAPS surface for authenticated practitioner and patient messaging. Your application supplies its application credential and the user’s session; Sweet Potato operates the message service and persistence.

Mental Model

Request Requirements

Requirement	Purpose
Server-side secret key	Identifies the hosted SPAPS application
User session	Identifies the person reading or sending the message
Application access	Limits the request to the owning application’s data
Staging environment	Keeps integration tests and test messages out of production

Example Request


curl --fail-with-body \
  -H "X-API-Key: $SPAPS_API_KEY" \
  -H "Authorization: Bearer <user-access-token>" \
  --get --data-urlencode "patientId=<patient-user-id>" \
  --data-urlencode "practitionerId=<practitioner-user-id>" \
  https://api.sweetpotato.dev/api/secure-messages

This server-side example uses a staging secret key and a current user token. Replace both participant placeholders with their user IDs; the authenticated caller must belong to that pair. Continue with the returned cursor when paging; this endpoint rejects a nonzero offset.

Common Mistakes

Application identity does not replace user identity. Secure-message requests require an authenticated user context as well as an authorized application credential.

Treating API-key application identity as a substitute for user identity.
Putting the user’s bearer token in logs or analytics.
Exercising production conversations during integration tests instead of hosted staging data.