Native platform integration

Offer ISFY as a built-in option of your platform. Any merchant, store or brand on your platform enables sales recovery in one click, and every abandoned checkout, failed payment or new lead they generate becomes a phone call from an ISFY agent within seconds.

This guide is for platforms — checkout systems, storefront builders, telehealth and subscription platforms, CRMs, funnel builders, marketplaces and payment processors — that want to integrate ISFY once and make it available to all of their merchants. ISFY already consumes the native webhook formats of more than twenty platforms in production; the patterns below are the same for every one of them.

Integration models

A platform integration has two independent parts: the data path (how events reach us) and the handshake (how a merchant gets connected). Pick one of each.

Data path

Handshake

Native webhooks: we consume your format

If your platform already sends webhooks, the integration is a dedicated ISFY endpoint per merchant that speaks your format. We build and maintain the adapter; you send us what you already send everyone else.

What we adapt to

• Body format: JSON (flat or nested envelopes such as { id, event, data: { customer, order, subscription, payment } }), form-encoded, or query-string payloads.
• Event naming: any vocabulary. You tell us what each event means once; unknown event names are accepted, stored and ignored, never rejected, so you can add events without breaking us.
• Amounts: major units or minor units (*_cents), any ISO currency.
• Identity: order id, cart or session id, subscription id, customer id, funnel id. We follow whichever chain of identifiers your platform uses so that a later sale resolves the earlier abandoned checkout instead of creating a duplicate.
• Test deliveries: a test flag (for example is_test, test_mode, or a sandbox header) is honoured. Test deliveries are verified end-to-end and kept out of the dial queue.

Signature schemes we verify

We verify every delivery with a constant-time comparison before anything is processed. Supported out of the box:

If your scheme is not listed, send us your webhook documentation. Adding a scheme is a small, well-trodden change on our side.

Delivery semantics

• Response: 2xx for every authenticated, well-formed delivery, including events we ignore. The response body carries an outcome so your logs show what happened (ingested, ignored, skipped_no_phone, duplicate).
• Errors: 401 only for a failed signature or wrong secret; 5xx only for a transient fault on our side. Retry on 5xx with any back-off.
• Idempotency: we key on your delivery id when you send one, and on the business id (order, cart, subscription) otherwise. Replays never create duplicates. A replayed delivery id with a changed body replaces the earlier receipt and is reprocessed.
• Ordering: irrelevant. A sale that arrives before its abandoned checkout still resolves to one completed lead.
• Latency: accepted in well under a second; the lead is in an agent's queue within seconds.

Event mapping

Whatever your vocabulary, every event maps to one of four things ISFY does. During onboarding we agree the mapping from a list of your event names; the table shows the categories and typical native names.

One-click connect

The merchant clicks Enable ISFY inside your platform and is connected without touching webhook settings. The flow is a standard redirect handshake.

1. Redirect. Your platform sends the merchant to the ISFY connect page:

   GET https://app.isellforyou.com/connect/{platform}
       ?merchant_id={your merchant id}
       &merchant_name={display name}
       &email={merchant contact email}
       &return_url={where to send them back}
       &state={opaque anti-CSRF value}
       &sig={HMAC-SHA256 of the query, partner secret}

2. Account. The merchant signs in to ISFY or creates an account (pre-filled from the query). Existing ISFY customers are linked, not duplicated.
3. Provisioning. ISFY creates the merchant's connection and mints their endpoint URL and signing secret.
4. Registration. One of two ways, agreed during onboarding:
   • ISFY calls your webhook registration API with the endpoint URL, secret and subscribed events, using a partner credential you issue to us; or
   • ISFY redirects back to return_url with state, connection_id, endpoint_url and secret, and your platform stores and registers them.
5. Done. The merchant lands back in your platform with ISFY shown as connected. The first delivery arrives within seconds of their next event.

Provisioning API (server-to-server)

When your platform owns the settings UI and prefers no redirect, your backend provisions the connection directly. One call per merchant.

Authorization: Bearer {partner token}
Content-Type: application/json

{
  "merchant_id":   "m_10293",          // your stable id, idempotency key
  "merchant_name": "Acme Health",
  "email":         "ops@acmehealth.com",
  "phone":         "+15551234567",     // merchant contact, optional
  "events":        ["checkout.started", "payment.failed", "order.completed"],
  "metadata":      { "plan": "pro", "region": "US" }   // optional, echoed back
}

// 201 Created
{
  "connection_id": "c_8f2a…",
  "endpoint_url":  "https://{BASE_URL}/webhooks/{platform}/c_8f2a…/{SECRET}",
  "signing_secret": "whsec_…",     // use it to sign deliveries, if your platform signs
  "status":        "active",
  "portal_url":    "https://app.isellforyou.com/…"   // merchant's ISFY dashboard
}

Responses are JSON; errors use conventional status codes with a machine-readable error.code. The partner token is issued during onboarding, scoped to your platform, and rotatable on request.

Merchant lifecycle

Outcome writeback (optional)

Platforms that want results inside their own product can receive them. When an ISFY agent reaches a lead, books an appointment or recovers a sale, we can push the outcome to your platform as a tag, note, status change or webhook, using your API. This is agreed per platform during onboarding and is already live with several partners.

Testing

• Test connection. We issue a sandbox connection on request. Deliveries to it are verified and logged exactly like production but never dialed.
• Test flag. Deliveries carrying your platform's test marker are recognised on production connections too.
• Delivery log. Every delivery is stored with its event name, signature status, outcome and any processing note. During onboarding we share it with you so you can see each test land.
• Acceptance. One test delivery per event category, each landing with a working phone number, is the success criterion.

Go-live checklist

1. You send us: your webhook documentation (or one sample payload per event), your signature scheme, and which handshake model you want.
2. We build the adapter for your format and confirm the event mapping with you. Typical turnaround is days, not weeks.
3. We exchange partner credentials (connect signing secret or provisioning token).
4. Pilot with one merchant: connect, fire one event of each category, confirm each landed end-to-end.
5. Listing. ISFY appears in your integrations directory, marketplace or settings page. We supply copy, logo and a merchant-facing setup guide.

Then we're live: any merchant on your platform enables ISFY in one click, and every event becomes a phone call from an agent within seconds.