Product · Integrations & API

Connect, test and launch.

One endpoint in, signed webhooks out. Keys are prefixed fh_live_ and fh_test_ — the test key writes to a sandbox that renders everything and sends nothing.

How Flyhalf connects

Three ways in. None of them touch your checkout.

Flyhalf receives copies of events from your systems after they happen, so it never sits between a customer and a sale.

PathwayBest forHow it worksDeveloper time
Store plugins WooCommerce stores
Shopify In development
Install the WooCommerce plugin and orders, refunds, registrations and reviews arrive as Flyhalf events.
Product views and carts In development
None
REST API Custom apps, POS and PMS Signed webhooks, delivery logs with replay, and idempotency keys so a network retry never awards points twice. Needed for the initial integration; marketers then work in the Flow Builder
Managed service Enterprises that want strategic support The Flyhalf team builds the integration and plans and runs campaigns with you. Talk to us. Handled by Flyhalf

Ingest

One POST. Any JSON payload.

Send the events your systems already emit. Set an Idempotency-Key and retries are free: the same key is accepted, deduplicated and never double-processed. Events that match no flow are still ingested, validated and stored.

INGEST AN EVENT bash
curl -X POST https://api.flyhalf.run/v1/events \
  -H "Authorization: Bearer fh_test_…" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: evt_9f31" \
  -d '{
    "event_type": "order.completed",
    "participant": { "external_id": "cus_84h2" },
    "payload": { "total": 349.00 }
  }'

→ 202 accepted · queued for processing
VERIFY A WEBHOOK SIGNATURE php
$expected = hash_hmac('sha256',
    $timestamp.'.'.$body,
    $signingSecret);

if (! hash_equals($expected, $signatureHeader)) {
    abort(401); // not from Flyhalf — drop it
}

Webhooks out

Signed, timestamped, replayable.

Every outbound webhook carries an HMAC signature over a timestamped payload — verify with a constant-time compare and reject anything stale. Failed deliveries retry on a backoff schedule, then dead-letter with one-click replay from the dashboard.

  • Delivery log with status and response codes
  • Retries: 1m → 5m → 30m → 2h → 12h, then dead-letter
  • Webhook events for badges, points, redemptions, finished flows and sent messages

The boring guarantees

What you'd build anyway — already built.

Idempotency everywhere

Events dedupe on your key; flow side-effects derive their own. At-least-once delivery, exactly-once effects.

Sandbox as a dimension

fh_test_ keys write sandbox data through the whole stack. Messages render and log as simulated — never sent.

Versioned API

Everything under /v1. Breaking changes get a new version, not a surprise deploy.

Append-only ledger

Points are never edited in place. Reversals reference the original entry, so audits reconcile to the cent.

WooCommerce, one install

Drop in the WordPress plugin and Woo orders, refunds, registrations and reviews arrive as signed Flyhalf events — HMAC-signed, idempotency-keyed, queued off the checkout request. No code to write.