Direct Mobile Document Ingestion to OpenClaw: iOS to Raspberry Pi Health Workflow

A developer on r/openclaw has documented an experimental pattern for pushing documents directly from a mobile iOS client into a local OpenClaw instance running on a Raspberry Pi. The goal is to scan documents like lab results or prescriptions on a phone and have them land in OpenClaw for downstream processing without cloud intermediaries or manual uploads.

Architecture Overview

The system uses a two-layer approach: the phone acts as the capture layer, and OpenClaw serves as the processing layer. The mobile client is designed to be fully local and privacy-preserving, with no cloud dependency and no external AI services. It uses Apple OCR (Vision) and on-device intelligence for extraction and search, keeping raw documents and extracted content on-device unless explicitly pushed to OpenClaw.

Pairing and Configuration

A QR-based pairing flow avoids manual configuration. The QR payload is a base64-encoded JSON blob generated on the OpenClaw machine with this structure:

{ "url": "wss://", "bootstrapToken": "", "hooksToken": "", "agentId": "", "hookPath": "/hooks/rkive" }

The hooksToken is stored in iOS Keychain, non-sensitive config is in local storage, and the wss:// URL is converted to https:// for push requests.

Data Flow

The iPhone mobile client sends a POST request to /hooks/rkive with a Bearer token ({hooksToken}) and a JSON payload containing a base64-encoded PDF. This lands on the OpenClaw instance (Raspberry Pi, on local network or VPN), which runs an ingest_rkive.py transform script. This script saves the original PDF to health-records/originals/, upserts an index record to health-records/index.jsonl, and handles chunked assembly and abort cleanup. A dedicated health agent then manages downstream processing: OCR → validation → structured output.

Key Design Decisions

• Dedicated Agent in OpenClaw: A multi-agent setup includes a dedicated health agent responsible for document ingestion, validation, and downstream structuring, keeping health-related workflows isolated.
• Dedicated Endpoint: Using a fixed endpoint like /hooks/rkive instead of dynamic routing via agentId ensures deterministic routing, avoids accidental misclassification, and simplifies server-side logic.

Downstream Workflow and Open Questions

The downstream workflow is a work in progress. Since Apple OCR is noted as not reliable for 100% accuracy, the plan involves re-extracting text into clean markdown in OpenClaw using the user's trusted AI workflow, followed by a human validation step for content verification, structured extraction into FHIR-style resources, appending into a longitudinal dataset, and providing health insights.

The author poses two open questions for community feedback: 1) Whether this pattern feels useful in practice for regular use versus being too much friction, and 2) What people would want OpenClaw to do with personal health records once ingested, suggesting ideas like longitudinal event timelines, detecting gaps (e.g., missed follow-ups), and periodic summaries.