Security & data
What we verify on every delivery, how credentials are issued and rotated, and exactly which data RunningSales needs from your platform and which it does not.
Transport & authentication
- HTTPS only. Every RunningSales endpoint is TLS 1.2+; plain HTTP is not served.
- Per-connection endpoints. Each merchant connection has its own URL containing an
unguessable secret. A delivery to the wrong URL is rejected with
401before the body is read. - Signature verification. When your platform signs webhooks, we verify the signature with a constant-time comparison before processing. Unsigned deliveries to a connection that expects a signature are rejected. Supported schemes are listed in the native integration guide.
- Replay protection. Timestamped signature schemes are checked against a tolerance window; delivery ids are recorded so replays are recognised.
- Outbound calls (feed polling, outcome writeback, webhook registration) use the
credential you issue to us, sent only in an
Authorizationheader, never in a URL.
Credentials
| Credential | Issued by | Scope | Rotation |
|---|---|---|---|
| Endpoint secret | RunningSales, per connection | Accept deliveries for one merchant | On request; old secret revoked immediately. |
| Signing secret | Your platform (or RunningSales, if you prefer) | Sign deliveries for one merchant | Stored encrypted at rest (AES-256-GCM); rotate any time, we accept the new value from the next delivery. |
| Feed / writeback token | Your platform | Read-only feed, or the minimum write scope for outcomes | Your policy; we never need more than the stated scope. |
If a credential leaks, tell your RunningSales contact or email integrations@runningsales.com. We revoke and reissue within the hour and confirm no deliveries were accepted from the leaked credential after the report.
Data we need, and data we do not
RunningSales exists to make a phone call. The data required is what an agent needs to place and personalise that call and what the merchant needs to see the result.
| Data | Needed? | Why |
|---|---|---|
| Phone number | Required | Without it the lead cannot be worked and is skipped. |
| Name, email | Recommended | Personalises the call; email de-duplicates across sources. |
| Event type, amount, product, currency | Recommended | Routes the lead to the right queue and tells the agent what is at stake. |
| Stable ids (order, cart, subscription, customer) | Recommended | Links events for one person so a sale closes the earlier lead. |
| Recovery / resume link | Optional | Lets the agent send the customer straight back to their checkout. |
| Address, timezone, locale | Optional | Call timing and compliance with local calling hours. |
| Card numbers, bank details, CVV | Never | We do not take payments on your behalf; do not send them. |
| Medical, intake or health-questionnaire data | Not needed | Agents recover the order, they do not consult. Contact and order data is sufficient. |
| Passwords, tokens, session cookies | Never |
Privacy modes that strip contact fields. Some platforms offer a
"safe fields only" or "hashed contact info" webhook setting. Hashed phones cannot be dialed
and stripped payloads cannot be worked. For an RunningSales integration, merchants need a way to
share contact and order fields without being forced to share regulated categories they do
not need to share. If your platform has such a mode, we recommend a contact-only option so
merchants can enable RunningSales without a separate compliance review.
Data handling
- Purpose. Data received through a connection is used only to work the merchant's leads and report results to that merchant (and, in aggregate, to your platform). It is not sold, shared with other merchants, or used for any other purpose.
- Tenancy. Each merchant's data lives in its own account with row-level access control; agents see only the campaigns they are assigned to.
- Storage. Deliveries are stored as received for audit and replay, with secrets encrypted at rest. Contact records are de-duplicated per merchant.
- Retention. Lead and call records are retained for the life of the merchant's account and deleted on request when the account closes. Raw delivery logs are retained for a rolling operational window.
- Calling compliance. Leads are called within permitted hours for their timezone, opt-outs are honoured across all campaigns, and per-lead dial caps prevent repeated attempts. Call recordings are available to the merchant.
- Subprocessors. Telephony, SMS and hosting providers are listed for merchants on request. Agreements covering data protection are available for platforms and merchants that require them; ask your RunningSales contact.
Reliability
- Availability. Ingest endpoints are stateless and horizontally scaled; accepted deliveries are persisted before we respond.
- Accept first, process after. A well-formed, authenticated delivery is acknowledged
with
2xxand processed asynchronously, so a slow downstream never causes your platform to retry. - Idempotent by design. Retries, duplicate deliveries and out-of-order events all resolve to one lead. Retry as aggressively as you like.
- Observability. Every delivery is logged with event name, signature status and outcome. During onboarding we share the delivery log so both sides see the same thing.
- Backfill. When your platform offers a read API, we can backfill missed windows after an outage on either side, within your rate limits.