How do I send Apple Health data to n8n?

What do you get?

Syncky Health sends selected Apple Health data to your n8n workflow through a direct webhook. You can receive data and, when explicitly permitted, request write-back with source and undo. Free during launch; plans are coming later. See launch access and pricing.

What do you need before setup?

This direct webhook route does not require MCP or Syncky Relay, and no agent pairing is needed. You need Syncky Health and an n8n endpoint reachable from the iPhone. Choose the data types and workflow destinations deliberately, including any AI model that may receive them.

Your iPhone sends selected data to your n8n server, which receives plaintext inside the connection. Nothing passes through Syncky's servers on this route. You control its storage and workflow destinations; if a workflow forwards data to an AI model, that model receives what you send. iOS schedules background work and Health reads require an unlocked iPhone, so deliveries can be hours late.

How do you set up n8n?

  1. Add a Webhook node using POST and a path such as syncky-health.
  2. Choose Header Auth, with a credential named X-Api-Key and a long random value. Enter that value privately in the app's matching Header authentication setting. Never put it in a URL or logs.
  3. Activate the workflow and use the production /webhook/ URL, for example https://n8n.example.net/webhook/syncky-health. The /webhook-test/ URL works only while the editor listens.
  4. In Syncky Health, add the n8n server template, choose Syncky JSON and select the types to send. Grant the selected Health read permissions.
  5. Handle empty tests and results as described below, then tap Check connection. Expect a successful acknowledgment with no writes. Only after that, deliberately use Sync now to send the selected data.

The canonical server contract describes the recipe. Node names/options and raw-body handling are not verified by Syncky. If you enable request HMAC, verify it against the raw body with the timestamp/replay rules in the signature contract. Header authentication alone does not verify that signature. Prefer HTTPS.

What can n8n read and write?

A native JSON data delivery contains the selected body.samples and body.deleted; tests and results need separate handling below. Write only owner-requested entries or entries covered by explicit standing approval. No write is part of the first connection check.

Turn on Accept writes to Health for this server, select allowed types and grant the corresponding iOS Health write permissions. Configure Respond to Webhook to answer a data delivery with 2xx, Content-Type: application/json, and a commands message no larger than 65,536 bytes. This synthetic empty reply grants no writes:

{"v":1,"type":"commands","commands":[]}

For an actual requested entry, use the write-back contract: stable command_id, increasing version for changes, supported type, unit and timestamps. Keep a command until its latest result arrives, so a retry does not create a new command. Writes are restricted to supported and allowed types; entries mark this server as their source. Replies to tests or results cannot issue writes.

Over plain HTTP, enable signing and return a signed reply covering the request's delivery id, timestamp and exact reply bytes. Its time must be within 300 seconds of the phone's clock. HTTPS replies do not require that signature. See the contract rather than substituting the request signature for the reply signature.

A queued or sent write is not an applied write: inspect the latest command result after sync. For undo, the same command contract permits a delete of that command's own record with the same id and a higher version; the iPhone also has a remove-written-entries control. This guide does not implement a write workflow.

How do you test the connection?

Check connection sends an empty test delivery with no health data. Read body.delivery.test before processing body.samples and body.deleted. Respond successfully to tests without queuing writes. Handle a request with X-Syncky-Kind: results as command results rather than sample data, and return 2xx with an empty body. Do not log auth headers, signatures, request bodies or results bodies.

Keep workflow examples synthetic. Use the protocol's test vectors to check your receiver without real Health data.

Expect 2xx with an empty body for Check connection and results. A successful check establishes endpoint/authentication reachability, not fresh or complete Health data. Then deliberately use Sync now for the types you chose, without testing a write.

How do you troubleshoot this setup?

What are the frequently asked questions?

When will data and commands arrive?

A command can arrive only in a reply to a data delivery; if the phone has nothing new to send, it makes no data request and the command waits. Background timing depends on iOS and the unlocked iPhone. Keep the stable command id until the result for its latest version arrives.

Does Header Auth verify a Syncky HMAC signature?

No. It checks the configured header credential. Request HMAC needs exact raw-body bytes and the timestamp/replay checks in the signature contract. The repository recipe does not establish how your n8n deployment preserves those bytes.

Can I use the Home Assistant recipe for write-back?

Home Assistant uses the same direct route but its empty webhook replies cannot write back. n8n needs an intentional permitted command response and separate results handling.

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