How to send Apple Health data to Make

What do you get?

Syncky Health sends selected Apple Health data to a Make direct webhook, and your scenario forwards it to chosen destinations. Free during launch; plans are coming later. See Syncky launch access and pricing; Make's service plan is separate.

This route does not require MCP or Syncky Relay, and no agent pairing is needed. Nothing passes through Syncky's servers on this route. Make receives plaintext inside the connection. Its webhook documentation says incoming requests enter a queue even with confidential-data settings, and webhook logs include headers and bodies. Review access and retention before sending. iOS schedules background work and Health reads require an unlocked iPhone, so deliveries can be hours late.

What do you need before setup?

Use Syncky Health, a Make scenario with a Custom webhook, and a deliberately chosen destination. Choose Health Auto Export JSON for metric-oriented processing or Syncky native JSON for sample UUIDs, deletions and device identity. This is a receiving workflow with no Health write-back.

Make's Custom webhook documentation confirms API-key authentication, JSON pass-through and the payload limit below. Not verified by Syncky: a live Syncky-to-Make scenario. Validate your configuration with synthetic records before sending selected data.

How do you set up Make?

1. Add the Webhooks app's Custom webhook module to a scenario and create a webhook, following Make's module documentation. Copy its HTTPS URL privately.
2. In the webhook's API Key authentication, add a key and save it privately. Make requires ASCII characters and at most 512 characters.
3. In Syncky Health, open Settings › Connections › + › Server or automation. Enter the webhook URL, choose Health Auto Export JSON or Syncky native JSON, and choose Header with name x-make-apikey and that key as Value. If you leave Make's optional API-key authentication off and choose None in Syncky, the URL is the only secret, and anyone who obtains it can submit requests. Keep it out of screenshots, shared scenario exports and logs. Select types and grant their Health read permissions. Keep Accept writes to Health off.
4. Before destination modules, branch native delivery.test: true and empty HAE arrays to an acknowledgment without processing samples. Iterate native samples, or HAE metrics and their data points; do not treat an empty envelope as a sample. Keep tests and native results out of destination actions.
5. Tap Check connection. Make documents a default 200 response with Accepted when the request is queued; a Webhook response module can customize the reply. After the check succeeds without destination records, enable the intended scenario processing and deliberately use Sync now. Check downstream execution separately from receipt.

Not verified by Syncky: empty-array mapping, destination modules and their permissions in your scenario. Use synthetic records to validate them before sending selected Health data.

What can Make read and write?

Make documents incoming API-key authentication in the Custom webhook settings. Bearer and Basic checks would require custom scenario logic; no built-in verifier for either is documented there.

Make's module documentation says JSON pass-through exposes the original JSON as text; Advanced settings → Get request headers exposes incoming headers. Not verified by Syncky: byte-for-byte body preservation or a working Syncky HMAC verifier in Make; reserializing parsed JSON is insufficient. If you require HMAC, verify at an upstream receiver using authentication and signatures: the whole whsec_ secret as the UTF-8 key, HMAC-SHA256 over timestamp + . + exact raw bytes, constant-time signature comparison, a 300-second window and replay handling.

Syncky permits x-make-apikey as a custom header name; it forbids Authorization, Content-Type and X-Syncky-* as custom headers. Use the key created for the webhook, not a Make account management API token. Make sanitizes x-make-apikey so its value is not exposed to scenario mapping. A downstream scenario check cannot prevent Make from receiving the body, and the default queued acknowledgment does not prove that check passed. Not verified by Syncky: custom Bearer or Basic checks in a live scenario.

This route has no Health write-back. Native records use (device, uuid), adding part for split series; process deleted separately. HAE omits sample UUIDs and deletions. Replace repeated records rather than adding values again, and keep Accept writes to Health off.

How do you test the connection?

Check connection sends no health data: HAE sends {"data":{"metrics":[],"workouts":[]}}; native sends empty arrays with delivery.test: true. Require 2xx and no destination records. An empty body is sufficient; Make's default Accepted body is also usable because the app ignores test replies. A successful check proves HTTP receipt, not completion of your scenario or freshness of Health data.

Make documents a maximum webhook payload of 5 MB (5,242,880 bytes), measured by Content-Length, on every subscription tier in its module documentation. Syncky starts with request bodies up to 1,000,000 bytes, below that limit. Each 413 halves its body limit, down to 65,536 bytes on a later attempt. Make's documented limit accommodates both the initial and reduced batches; a 413 still requires checking the actual rejecting service. An intermediate receiver limit below 65,536 bytes cannot be solved by further Syncky shrinking. Keep the response within the app's 30-second timeout. See responses and limits.

Make's webhook overview documents up to 300 incoming requests per 10 seconds, with 429 above that rate. Each webhook's queue allows up to 667 items per 10,000 monthly licensed credits, capped at 10,000 items; excess arrivals are rejected with 400 when full. These request and queue limits are separate from the payload byte limit.

Inspect status and counts without printing full URLs, authentication headers, signatures or request/results bodies. Make's logs can contain these; do not share their contents as troubleshooting evidence.

How do you troubleshoot this setup?

• Authentication fails: confirm Make's API Key authentication has the saved webhook key and Syncky sends it in x-make-apikey. Compare private settings without logging the key; do not substitute an account API token.
• A test makes a blank destination record: branch on the native test flag or empty HAE arrays before iterating data.
• 400 / 429: Make documents queue-full and rate-limit responses. Inspect scenario/queue state; a failed HTTP delivery is retried by Syncky.
• 413: inspect the rejecting service's byte limit. Syncky halves later batches to its 65,536-byte floor; a sample count alone cannot establish body size.
• 200 but no destination data: queued receipt is not scenario completion. Check downstream failures and deliberate activation, selected types, Health read permissions and an unlocked iPhone.

What are the frequently asked questions?

Does a successful check mean the scenario finished?

No. The check confirms HTTP receipt. Test destination mappings separately with synthetic records.

Can this scenario feed a spreadsheet?

Use the Google Sheets guide for row mapping, no-data guards and deduplication. Configure and test your chosen connector separately; this guide supplies no packaged Make scenario.

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