How to send Apple Health data to Node-RED

What do you get?

Syncky Health sends selected Apple Health samples to a Node-RED direct webhook. A two-output function acknowledges the request and forwards samples to your chosen flow. Free during launch; plans are coming later. See launch access and pricing.

This route does not require MCP or Syncky Relay, and no agent pairing is needed. Nothing passes through Syncky's servers on this route. Node-RED receives plaintext inside the connection; protect its storage and every downstream destination. iOS schedules background work and Health reads require an unlocked iPhone, so deliveries can be hours late.

What do you need before setup?

You need Syncky Health and a Node-RED receiver reachable from your iPhone. The repository template is http://nodered.local:1880/syncky-health, Syncky JSON format and no authentication. Keep unauthenticated HTTP restricted to a trusted home network. For access beyond that network, configure HTTPS and authentication at your receiver or gateway, then match the app's authentication setting. This guide does not configure that deployment.

Choose the Health types and downstream destinations deliberately. The repository's Node-RED recipe establishes this flow; its node options and raw-body handling still need checking in your deployment.

How do you set up Node-RED?

  1. Create an http in node with method POST and URL /syncky-health.
  2. Connect it to a function node with two outputs. Paste the function below; connect the first output to http response and the second to your sample-processing flow.
  3. Keep the receiving endpoint on the trusted network, or configure HTTPS and authentication before using a wider network. Deploy the flow and keep request bodies and credentials out of debug nodes and logs.
  4. In Syncky Health, open Settings › Connections › + › Node-RED. Use the reachable host with the template path, Syncky JSON and matching authentication. Select types and grant their Health read permissions. Leave Health writes off for this flow.
  5. Tap Check connection and expect an empty successful acknowledgment with no samples forwarded. Then deliberately use Sync now to send the selected data.

Which function handles tests and samples safely?

Use the same two-output function as the canonical recipe:

const sync = msg.payload ?? {};
const samples = msg.req?.headers?.["x-syncky-kind"] === "results" || sync.delivery?.test || !Array.isArray(sync.samples) ? [] : sync.samples;
return [{ ...msg, statusCode: 200, payload: "" }, samples.length > 0 ? { payload: samples, device: sync.device } : null];

The first output retains the request/response context and answers with status 200 and an empty body. The second forwards a nonempty samples array and the device identifier. Tests, results and requests without a samples array forward nothing. This function does not store samples, process deletions or implement write replies; add deliberate downstream handling if you need storage or native deletions.

What can Node-RED read and write?

Node-RED receives the selected native JSON data. This flow returns an empty acknowledgment and has no Health write-back. Keep Accept writes to Health off. For intentional write-back with source and undo, use the native commands and results contract in a separately implemented workflow; this guide supplies no such flow.

The http in node parses JSON and does not keep raw bytes by default in the repository recipe. A JSON node does not verify HMAC. Request signing requires the exact raw bytes plus timestamp/replay checks in authentication and signatures; reserializing parsed JSON is insufficient. Leave signing off only on the trusted home network used by this recipe. HTTPS and header authentication do not by themselves verify a Syncky HMAC signature. Over plain HTTP, write replies require signing and a signed response; the empty acknowledgment here issues no commands.

How do you test the connection?

Check connection sends a test request with no health data. Expect status 200, an empty body and no sample output. A results request identified by X-Syncky-Kind: results also receives an empty acknowledgment. A successful check confirms endpoint reachability, not fresh or complete Health data. Use Sync now only after choosing the scope; no write belongs in the connection check.

Inspect status codes and connection state without logging authentication headers, signatures, full URLs, request bodies or results bodies. Use synthetic inputs when checking the function.

How do you troubleshoot this setup?

What are the frequently asked questions?

Does the function handle command results or deletions downstream?

It safely acknowledges results without forwarding them as samples, and only forwards the samples array from data deliveries. It does not consume results or propagate deletions. Implement those paths separately against the server contract if your storage needs them.

Can this receipt flow write an entry back into Health?

No. Its reply is empty. A separate native write workflow must implement the command/reply/results contract and obtain the owner's approval and Health permissions; changing the sample output alone does not grant write access.

Does a successful check mean the flow has current Health data?

No. The test contains no health data. Later deliveries depend on the selected scope, Health read permissions, an unlocked iPhone and iOS scheduling.

Agent setup · MCP comparison · All guides · Privacy · Public security policy · FAQ · Support.