Third-party API monitoring for backend teams

It's them,
not you.

Know in minutes when a third-party API you depend on starts failing, down to the endpoint, from your own traffic.

// one line at the top of your app
import { init } from '@theirside/sdk';
init({ apiKey, endpoint });

The alert you get

Sample incident · demo data

Acme Cards Failing

POST /v2/cards/:id/activate

38%

errors for 6 min, normally 0.2%

Other Acme Cards endpoints: OK

Ready to send to their support

req_8f2c41, req_8f2c97, req_8f2d03 and 41 more

Your error tracker says something failed. Not which provider endpoint.

When a provider degrades, the first hour goes into working out whose fault it is.

What you usually see

AxiosError: Request failed with status code 502 AxiosError: Request failed with status code 502 Error: socket hang up AxiosError: timeout of 10000ms exceeded

Is it us? Is it them? Which call?

Their outage looks like your bug

Providers often answer 401 or 404 during their own incidents. So teams start by debugging their own auth and routing code.

Hours later: "a partial outage on our side, now resolved."

The status page stays green

All systems operational

Vendor status pages update late, or not at all for the one endpoint you call.

Acme Cards POST /v2/cards/:id/activate is failing 38% for 6 minutes, normally 0.2%. Other Acme Cards endpoints are fine.

Plus request IDs to paste straight into an email to their support.

How it works

Three parts, all in your infrastructure. Nothing to configure per vendor.

  1. SDK in your app

    One line, zero config. Every outgoing call to a third-party API is recorded and grouped into providers: fetch, http/https, Axios, @nestjs/axios. Bounded memory, never slows or breaks the app.

    init({ apiKey, endpoint })

  2. Self-hosted collector

    One Docker image and your Postgres. Learns what normal looks like for each endpoint and scores it every minute. Dashboard and health API included.

    docker compose up -d

  3. Alerts you can act on

    Slack, email or a signed webhook, one incident per provider. Each comes with a paste-ready summary for the provider's support: endpoint, rates, timing, request IDs.

    Slack · email · webhook

  • Behaviour change, any status

    Not only 5xx. An endpoint that starts answering 401, 404 or 422 where it used to answer 200 opens an incident, judged against its own normal mix of statuses.

  • Per-endpoint baselines

    Seven days of history per endpoint, past incidents excluded. An endpoint that normally fails 3% stays quiet at 3%; a significant jump in errors or latency doesn't.

  • Low traffic handled

    A quiet endpoint is judged over a longer window until it has enough calls, so a real failure still alerts and one or two failed calls never do.

What an incident looks like

A mock incident from the Theirside demo stack: fake providers, fake traffic, the real format.

Acme Cards Open answering 401

POST /v2/cards/:id/activate

Opened 14:05 UTC · first bad minute 14:02 UTC · alerted to Slack #payments-alerts and email

401 responses, normally 0%
62%
calls in window, last 5 min
412
p95 latency, normally 420 ms
180 ms

Share of 401 responses, last 30 min

401 shareincident threshold

Other Acme Cards endpoints

Other Acme Cards endpoints in the same window
EndpointUnsuccessfulStatus
GET /v2/cards/:id0.1%OK
POST /v2/cards0.3%OK
GET /v2/transactions0%OK

Summary for their support

Acme Cards — POST /v2/cards/:id/activate answering 401 since 14:02 UTC (6 min)
Returns 401 for 62% of calls (normally 0%); credentials may have expired or the provider changed access rules; 412 calls in window.
p95 latency 180 ms (normal 420 ms).
Responses are fast (median 95 ms, normally 310 ms): calls fail before doing work. Other Acme Cards endpoints: OK.
Sample provider request IDs: req_8f2c41, req_8f2c97, req_8f2d03
Support: support@acmecards.test
Mock incident built from the Theirside demo stack. Acme Cards is a fake provider.

Your customers' data stays in your app

Paths are turned into endpoint templates inside your process before anything is sent. IDs and names become :id, so a customer's name in a URL never leaves your app.

The collector is self-hosted: one Docker image and your Postgres. Data stays in your infrastructure, with the retention you choose.

Never captured

  • Request and response bodies
  • Headers (only the provider's request ID is kept)
  • Query strings
  • Raw paths: endpoint templates only
  • Personal data
  • Internal and private-network hosts
/v2/customers/jane-doe-4821/cards
/v2/customers/:id/cards

Open source, free to self-host

Everything a single team needs to catch provider problems is free. Paid features for larger companies come later.

SDK: MIT

Adding @theirside/sdk to your app comes with no restrictions. Zero dependencies.

Collector: source-available

Fair Core License (FCL-1.0-ALv2): use, self-host and modify it for your own company. Each release becomes Apache 2.0 after two years.

Free now, paid features later

Alerts, dashboard, health API and a status page are free when self-hosted. Things like SSO, audit log and SLA reports will be paid.

Quick start

From zero to the first alert in about five minutes. Design partners get the compose file and a hand with setup.

  1. Run the collector and Postgres

    THEIRSIDE_VERSION=0.3.0 \
    THEIRSIDE_BOOTSTRAP_API_KEY=tsd_live_$(openssl rand -hex 16) \
    THEIRSIDE_ADMIN_TOKEN=$(openssl rand -hex 24) \
      docker compose -f docker/docker-compose.yml up -d
  2. Add the SDK

    npm i @theirside/sdk
    import { init } from '@theirside/sdk';
    
    init({ apiKey: process.env.THEIRSIDE_API_KEY, endpoint: 'http://localhost:4318' });
  3. Connect an alert channel

    Open http://localhost:4318, add Slack, email or a webhook under Settings → Alert channels and send a test alert. Providers appear within a minute of the first calls.

Become a design partner

Free setup help, a direct line to the people building it, and a say in what comes next.