Pagination, Errors, and Retries

Handle Memo list responses, validation and authorization errors, and safe retry behavior.

Pagination

List endpoints commonly accept these query parameters:

Parameter	Meaning
`limit`	Maximum number of returned items
`page`	One-based page number
`offset`	Number of items to skip
`sortBy`	Field and, where supported, sort direction
`search`	Free-text filter

Resource-specific filters such as organization, patient, name, or role are documented per operation.

List responses commonly use an envelope like this:

{
  "results": [],
  "page": 1,
  "limit": 50,
  "totalPages": 0,
  "totalResults": 0
}

Some operations return a plain array. Write clients against the response shown for the exact endpoint and pin schema changes in your integration tests.

Error responses

Validation and request errors use a JSON object with a numeric code and message:

{
  "code": 400,
  "message": "Validation error"
}

Common statuses are:

Status	Meaning	What to do
`400`	Invalid ID, query, or body	Correct the request; do not retry unchanged
`401`	Missing, expired, or unknown credential	Replace or refresh the credential
`403`	Valid identity without access	Check role and organization/patient ownership
`404`	Path or record not found	Check the path and resource ID
`405`	Method is not supported	Use the method shown in the reference
`5xx`	Server-side failure	Retry safe reads with backoff; investigate persistent failures

Do not display raw backend messages to end users. Log a request correlation value from your own service and retain only the minimum patient information required to investigate.

Retry policy

Retry GET requests only for transient network errors or 5xx responses.
Use exponential backoff with jitter and a small retry limit.
Do not retry 400, 401, 403, 404, or 405 without changing the request or credentials.
Do not automatically retry POST, bake/unbake, reset, reboot, registration, or other device commands. The schema does not advertise idempotency keys.
A repeated PATCH may still cause side effects; confirm the operation semantics before retrying.

Set a client-side timeout and cancel work when the caller disconnects. A timeout does not prove the server abandoned a write, so reconcile the resource with a read request before attempting the mutation again.

Error responses

Retry policy

Timeouts and cancellation

On this page