Native platform integration

Offer RunningSales as a built-in option of your platform. Any merchant, store or brand on your platform enables sales recovery in minutes, and every abandoned checkout, failed payment or new lead they generate becomes a phone call from an RunningSales 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 RunningSales once and make it available to all of their merchants. RunningSales 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

Model	How it works	Best when
Native webhooks	Your platform already emits webhooks. We consume your existing format and signature scheme as-is; you change nothing about your payloads.	You have a webhook system today. Fastest path for most platforms.
Events API	You POST our canonical JSON (four event types, one endpoint) from your webhook triggers.	You are building the integration from scratch or prefer a fixed schema.
Feed API	You expose a read-only feed and we poll it.	Webhooks are impractical on your side.

Handshake

Model	How it works	Merchant experience
Client portal	After onboarding, the merchant connects your platform from the Integrations page of the RunningSales client portal: they authorise it, paste an API key, or copy their dedicated endpoint URL into your webhook settings.	A few minutes, no platform work. This is how every integration starts.
Partner push	We issue your platform a delivery URL during onboarding and you send leads on your merchants' behalf with the Events API.	Nothing to configure on the merchant side.

Nothing to install, nothing to host. Every model above is an HTTPS exchange. There is no SDK, no library, no fee, and no change to your checkout or your data model.

Native webhooks: we consume your format

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

POST {BASE_URL}/webhooks/{platform}/{CONNECTION_ID}/{SECRET}

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:

Scheme	Typical header
HMAC-SHA256 of the raw body, hex or base64 encoded	`X-{Platform}-Signature`, `X-Webhook-Signature`
Prefixed digests (`sha256=…`)	`X-Hub-Signature-256` style
Timestamped signatures (`t=…, v1=…`) with replay window	`{Platform}-Signature`
HMAC over `{timestamp}.{body}` with a separate timestamp header	`X-Signature` + `X-Timestamp`
Passphrase digests (SHA-512 / SHA-256 over sorted fields)	in-body `sha_sign` style
Secret-in-URL only (no signature)	none; the endpoint URL is the credential

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 RunningSales does. During onboarding we agree the mapping from a list of your event names; the table shows the categories and typical native names.

RunningSales category	Typical native events	What happens
New lead	`lead.created`, `contact.created`, `opt_in`, `form.submitted`	Enters the dial queue as a fresh lead.
Abandoned checkout	`checkout.started`, `cart.abandoned`, `order_form.filled`, `intake.incomplete`, `checkout_initiated`	Enters the recovery queue. Highest-value event: an agent calls within minutes. A recovery link, when your platform provides one, is shown to the agent.
Failed payment	`payment.failed`, `payment.declined`, `rebill.missed`, `invoice.payment_failed`, `subscription.past_due`	Enters the payment-recovery queue with the amount at stake.
Sale	`order.completed`, `payment.succeeded`, `subscription.renewed`, `purchase`	Completes the earlier lead, records revenue, suppresses further calls, and feeds buyer programmes (upsell, reorder, win-back) where the merchant runs them.
Refund / chargeback	`order.refunded`, `charge.disputed`	Recorded against the order; original paid amount is preserved for reporting.
Everything else	step telemetry, page views, tag changes, shipping updates	Accepted and stored, never dialed.

Contact fields must be present on the event. A lead is callable only if the delivery carries a phone number (email and name are strongly recommended). If your platform has a privacy mode that strips contact fields from webhooks, the integration must allow merchants to send contact data to RunningSales without also sending sensitive or regulated data they do not need to share. See Security & data.

Connecting merchants

A merchant is connected in one of two ways. Either way, events reach a dedicated RunningSales endpoint and every callable lead is dialed within seconds. There is no redirect or provisioning endpoint for your platform to call.

The merchant connects in the client portal

After a merchant signs up and finishes onboarding with RunningSales, they connect their stores, payment processors and CRMs themselves from the Integrations page of the client portal at app.runningsales.com/settings.

Onboard. The merchant creates a RunningSales account and completes onboarding.
Pick the source. On the Integrations page, the merchant picks your platform from the list of supported sources.
Connect. Depending on the platform, the merchant either authorises RunningSales, pastes an API key (we verify it and register the webhook with your platform for them), or copies their dedicated endpoint URL into your webhook settings.
Done. The portal shows the source as connected, and the first delivery arrives with the merchant's next event.

You push leads with the Events API

If your platform sends leads to RunningSales on its merchants' behalf, use the Events API: one HTTPS POST of canonical JSON per event, to the delivery URL we issue during onboarding. You can use one shared URL, or one URL per merchant for per-merchant attribution. The merchant has nothing to configure.

POST {BASE_URL}/webhooks/{source}/{CONNECTION_ID}/{SECRET}

The endpoint, payload, field reference and retry rules are documented in the Events API reference.

Your platform is not in the portal yet? Start with the Events API, or send us your webhook documentation and we build a native adapter for your format and add your platform to the Integrations page.

Merchant lifecycle

Moment	Your platform	RunningSales
Merchant enables RunningSales	Nothing, or start pushing their events with the Events API.	Connection created (by the merchant in the client portal, or by us during onboarding), endpoint issued, merchant sees a dashboard.
First events arrive	Nothing.	Signature verified, vocabulary confirmed, first leads dialed. Both sides can see the delivery log.
Sale recovered	Optional: receive an outcome writeback (see below).	Recorded as revenue on the merchant's dashboard, attributed to your platform.
Merchant disables RunningSales	Unregister the webhook, or stop pushing their events.	Deliveries stop; the merchant's data and history remain in their RunningSales account.
Secret compromised	Tell us.	New secret minted, old one revoked immediately.

Outcome writeback (optional)

Platforms that want results inside their own product can receive them. When an RunningSales 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

You send us: your webhook documentation (or one sample payload per event), your signature scheme, and which handshake model you want.
We build the adapter for your format and confirm the event mapping with you. Typical turnaround is days, not weeks.
We issue credentials: your Events API delivery URL, or the signing secret we agree for your native webhooks.
Pilot with one merchant: connect, fire one event of each category, confirm each landed end-to-end.
Listing. RunningSales 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 connects RunningSales from the client portal, and every event becomes a phone call from an agent within seconds.