API Testing (Partner Tests)

What it is

Partner Tests is a built-in API tester — a mini-Postman that lives inside opSentry. When a partner reports a problem (or an alert flags one), you don't have to guess: you send a real request to the endpoint and see exactly what comes back. It turns "a partner said something broke" into "we tested it, and here's the status code, body, and latency we got."

It's a Pro / Enterprise feature.

---

Where it lives

There are two entry points:

• Partner tests module on the dashboard — a panel covering all your partners. Good for a quick pulse check across the board.
• The full console scoped to one partner — open a partner's detail page and the Partner tests tab takes you into a console where every request, result, and saved check is scoped to that single partner.

The dashboard module is the overview; the partner detail console is where you actually build and run tests.

---

The three ways to run a test

1. Manual

Type a request by hand — method, URL, headers, body, auth, and assertions — then hit Run. This is the fastest way to poke at a single endpoint.

GET https://api.acme-bank.example/v1/health
Authorization: Bearer {{partner_token}}
Assert: status == 200

2. From Postman

Connect your Postman API key (Settings → Notifications → Postman), then pick a collection → request, and optionally a Postman environment. Hit Run and your collection variables and tokens resolve live — so a request that uses {{base_url}} and {{access_token}} runs exactly as it would in Postman.

3. Saved checks

Save a request against a specific partner so you can run it any time with one click — or have it auto-run when an alert affects that partner. Saved checks turn "is Acme Bank's auth still working after this release?" into a one-click (or automatic) answer.

---

Auth & tokens — the key part

Most partner endpoints are gated, so testing them realistically means testing them *authenticated*. Partner Tests gives you a few options:

• Your own token — supply a Bearer token, Basic auth, or an API key. It's stored encrypted and attached to the request when it runs.
• Live from a Postman environment — pull the token straight out of a connected Postman environment, so you're always testing with the current value rather than a stale copy.
• Override — drop in your own token for a single run to override whatever else is configured.

Because you control the token, you can deliberately test the 401 / 403 cases too — run with an expired or missing token to confirm the endpoint rejects it the way it should.

---

Assertions

Every run is a clear ✓ pass or ✗ fail, because you define the pass/fail rules up front:

• Status code — e.g. status == 200
• Body contains — e.g. response includes "status":"ok"
• Latency — e.g. response under 800ms

No squinting at raw output — the run tells you straight away whether the endpoint did what it was supposed to.

---

Set it up — a quick walkthrough

Using fake data to show the shape of it:

1. Open the partner Acme Bank → Partner tests tab.
2. Click New check.
3. Set the URL to https://api.acme-bank.example/health (GET).
4. Add an assertion: status == 200.
5. (Optional) Attach a token, or pull one from your Acme Sandbox Postman environment.
6. Save the check, then Run it.

You'll get back a ✓/✗ with the status code, response body, and latency. Results and history are per-partner — open Acme Bank again next week and you'll see every prior run, so you can tell whether something regressed.

---

What you can (and can't) test

Partner Tests only runs against your own verified domains — the product domains you've registered and verified under Settings → API Testing (one domain per workspace, matched to your business email). You cannot point it at someone else's API. The point is to confirm *your* endpoints — the ones your partners depend on — are healthy, not to probe third-party services.