What Are Webhooks (and Why Fitness APIs Use Them)?

A webhook is a server-to-server push notification: instead of your app repeatedly asking a provider "any new data yet?" (polling), the provider sends an HTTP POST to a URL you registered — your callback endpoint — the moment a relevant event happens, such as a user's wearable syncing a fresh workout. In other words, polling is your server pulling on a timer; a webhook is the provider's server pushing to you on an event. For fitness and health apps, that difference is what makes a recovery score or an activity feed feel current instead of minutes stale.

A bit more depth: what "the provider POSTs to your callback URL" means

Every webhook has two sides. You own an HTTPS endpoint — a route on your backend like /webhooks/strava — that sits and waits. The provider owns a subscription: a record that says "when event X happens for this app, POST to that URL." When the event fires (a new activity, a synced night of sleep, a deauthorization), the provider's servers open a connection to your endpoint and deliver a small JSON payload describing what changed. Your job is to accept it, acknowledge it fast, and process it.

One important nuance: many webhooks are thin. The payload often tells you that something changed and gives you an ID, not the full data. You then call the provider's regular API with that ID to fetch the details. So a webhook is frequently a doorbell, not a delivery — it tells you to go pick something up.

How it works

There are three moving parts to a working webhook integration.

1. Registration. You tell the provider one public HTTPS URL to notify, usually once, either in a developer dashboard or by calling a subscription endpoint.

2. The validation handshake. Before sending real events, most providers verify that you actually control the endpoint — commonly by sending a challenge value your endpoint must echo back. If the handshake fails, the subscription never activates.

3. Signature verification. Because your endpoint is public, providers sign each payload — commonly an HMAC hash in a request header — with a secret only you share. You recompute the signature over the raw body and reject anything that doesn't match.

The registration calls, exact handshake shape, and signature scheme differ per provider; the Strava integration guide walks a real one end to end. Conceptually, the payload a provider delivers is usually thin — it looks roughly like this:

{
  "object_type": "activity",
  "object_id": 1234567890,
  "aspect_type": "create",
  "owner_id": 9876543,
  "event_time": 1752345600
}

Notice there are no heart-rate samples or GPS points in that payload — just enough to know a new activity exists and whose it is. Your server acknowledges with a 200, then fetches the full activity by its object_id. The golden rule: respond quickly (a 2xx within a few seconds) and do the heavy processing after you've acknowledged, because providers treat a slow or failed response as a delivery failure and may retry or disable your subscription.

Polling vs. webhooks: the trade-off

Before webhooks, the only option was polling — calling the API on a schedule to check for changes. Polling is simple and needs no public endpoint, but it forces a bad choice:

The honest summary: polling is easier to stand up but scales badly on both freshness and rate limits; webhooks are more work to build correctly but are the right tool when data arrives unpredictably. Many robust integrations use webhooks as the primary path and a periodic poll as a backstop for anything a webhook delivery missed.

Why this matters for fresh wearable data

Wearable data does not arrive on a schedule — it arrives whenever a device syncs, which might be right after a run or hours later when the phone reconnects. That sporadic timing is exactly the case polling handles poorly: poll too often and you hit rate limits while mostly getting nothing back; poll too rarely and your app shows stale numbers. Webhooks sidestep the dilemma by delivering data the instant the provider has it. That is what lets recovery scores, live activity feeds, and timely coaching nudges feel current rather than lagging. Health-data aggregators and cloud providers commonly deliver data via webhooks for this reason (some also offer streaming or polling).

A concrete example in a fitness app

A user finishes a run. Their watch syncs to Strava's cloud. Strava's servers POST a thin event to your /webhooks/strava endpoint saying "activity 1234567890 created for user 9876543." Your endpoint verifies the signature, immediately returns 200, and hands the event to a background job. That job calls Strava's API for activity 1234567890, pulls the distance, pace, and heart-rate stream, stores it, and updates the user's dashboard — all within seconds of the run finishing, with no polling loop running in the background. Once OAuth has authorized the connection, the webhook is what keeps it live.

Where this fits

This page defines the concept. When you're ready to wire one up, the hands-on guides go deeper:

• Setting one up for real: Integrating the Strava API walks through registering a subscription, answering the validation handshake, and verifying signatures end to end.
• When it breaks: Strava webhook not firing covers the usual culprits — a failed handshake, an unreachable URL, or a subscription that never activated — and wearable data delayed covers when events arrive but late.
• The bigger picture: webhooks are the delivery half of most health-data aggregators, which push normalized data from many devices to a single endpoint you own.