Skip to main content

Integrations

Disconnect a provider

Remove a payment provider — and the revenue data that came with it.

DELETE/sites/{siteId}/integrations/{provider}
Disconnect a payment provider
curl --request DELETE \
  --url 'https://truestat.io/api/v1/sites/{siteId}/integrations/{provider}' \
  --header 'Authorization: Bearer <token>'
{
  "data": {
    "provider": "stripe",
    "connected": false,
    "revenue_deleted": true
  },
  "meta": {
    "site_id": "6fed8980-a119-4a9c-a4d4-53e448ef9f9e"
  }
}

Removes a payment provider from a site.

This deletes revenue data, not just the connection

The name suggests a credential is being removed. What actually goes is the credential and every payment, provider event and subscription row stored for this site, in both stores. This is the same thing the dashboard's disconnect button does — it is not a heavier version for the API.

Reconnecting and importing history brings the payments back.

It does not bring back the lifecycle events that only a live webhook could have recorded — an upgrade, a pause, a resume, a trial converting. A provider's API can describe a subscription as it stands today; it cannot say that it changed last March.

If what you want is correct figures rather than a removed integration, use POST …/resync, which keeps both.

The webhook goes first

The order is not an implementation detail:

  1. Delete the endpoint at your provider

  2. Then delete the stored data

  3. Then the connection record

Deleting our record first would leave an endpoint standing in your account, delivering into a 404 — with the key gone, so neither side could remove it. You would have to delete it by hand.

So if the webhook cannot be removed, nothing is removed and the call answers 502 with what to do. That happens when the key was revoked at the provider before disconnecting here: delete the TrueStat endpoint in your provider's dashboard, then call this again.

The provider in the path must match

A site holds one connection. Naming a different provider disconnects nothing and answers 404 — a typo in a URL should not destroy an integration.

Both "not connected at all" and "connected to something else" give the same 404 not_connected with the same message — the same code re-syncing uses for that condition, so a caller branching on code handles one fact, not two spellings of it.

Which provider a site uses is a question for GET /integrations, behind the read scope.

Afterwards

The site keeps collecting analytics. Only the revenue side is gone — traffic, goals, sources and everything else are untouched.

Authorizations

Authorizationstringheaderrequired

An API key from Settings → API keys. Scopes available: analytics:read, sites:read, sites:write, settings:read, settings:write, goals:read, goals:write, funnels:read, funnels:write, notes:read, notes:write, alerts:read, alerts:write, team:read, team:write, revenue:read, revenue:write.

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path parameters

siteIdstring (uuid)pathrequired
The site's id, from `GET /sites`. A site that is not yours and a site that does not exist both answer 403, so this cannot be used to discover other people's ids.
providerstringpath
Must match the provider actually connected, or the call is a 404.

Response

application/json

The answer.

dataobject
metaobject