Cybersecurity, Identity & Fraud
Third-Party Vendor Risk API
You are accountable for vendors you cannot audit. The questionnaire they returned is a year old, self-reported, and describes intentions.
- GRC and vendor risk platforms
- Insurers
- Procurement teams
- Managed security providers
- Banks
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Vendor risk management is mostly paperwork measuring the wrong thing. A questionnaire captures what a vendor says about itself at one moment, usually written by someone in sales rather than security, and then sits unchanged while the vendor acquires a company, migrates a platform and changes three authentication providers. The assessment is stale within weeks and nobody re-runs it because re-running it is expensive.
Externally observable signals have the opposite shape: narrow, shallow, and continuously current. Certificate hygiene, email authentication policy, exposed service inventory, public breach disclosure, domain configuration and leaked-credential appearance can all be observed from outside, refreshed daily, across a thousand vendors without anyone filling in a form. For monitoring between formal assessments, that trade is often worth making.
The honest framing matters, though, because this category has a history of overclaiming. An external score measures the tidiness of a vendor's internet-facing surface. That is real information — it correlates with engineering discipline — but a vendor with immaculate external hygiene can still have no access review process, unmonitored privileged accounts, or a single unsegmented network. Treating an external grade as a security verdict is a mistake we would rather name in the proposal than let a buyer discover after they have replaced their assessment programme with a dashboard.
Who buys this
GRC and vendor risk platforms, Insurers, Procurement teams, Managed security providers, Banks
What the API returns
What comes back
- A posture profile per vendor assembled from externally observable signals
- Certificate, DNS and email authentication hygiene with the specific findings behind each
- Externally visible service inventory from passive observation, plus authorised checks where the vendor consents
- Public incident and breach disclosure history with sources and dates
- Leaked-credential exposure indicators for the vendor's domains
- Fourth-party dependency mapping — the providers your vendor visibly relies on
- Change detection, so a degrading vendor is flagged rather than re-scored silently
- Explicit scope statement per profile: what was observed, what was not, and what the signals cannot tell you
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/vendors | Register a vendor for monitoring with its known domains |
| GET | /v1/vendors/{id}/posture | Current posture profile with findings and scope statement |
| GET | /v1/vendors/{id}/incidents | Public incident and disclosure history |
| GET | /v1/vendors/{id}/dependencies | Observable fourth-party providers |
| GET | /v1/portfolio/summary | Portfolio view across all monitored vendors with concentration |
| WS | /v1/stream | Push posture degradation and new incident events |
Request and response
illustrativeRequest
{
"vendor_id": "ven_northgate",
"vendor": {
"name": "Northgate Data Services",
"domains": ["northgatedata.com", "ngd-platform.io"],
"tier": "critical",
"services_consumed": ["payment_reconciliation"]
},
"consent": { "active_checks_permitted": false },
"schedule": "daily"
}Response
{
"vendor_id": "ven_northgate",
"assessed_at": "2026-10-21T03:00:00Z",
"observation_scope": {
"mode": "passive_only",
"reason": "No authorisation on file for active checks",
"domains_observed": 2,
"not_observed": ["internal_controls", "access_governance",
"employee_practices", "non_internet_facing_systems"]
},
"posture": {
"score": 58,
"band": "needs_attention",
"components": {
"certificate_hygiene": 71,
"email_authentication": 34,
"dns_configuration": 62,
"visible_service_exposure": 55,
"credential_exposure": 48
}
},
"findings": [
{ "severity": "medium", "type": "dmarc_policy_none",
"asset": "northgatedata.com",
"evidence": "p=none, no aggregate reporting configured" },
{ "severity": "medium", "type": "certificate_expired",
"asset": "legacy.ngd-platform.io",
"evidence": "Expired 2026-10-02, host still resolving" },
{ "severity": "low", "type": "credential_exposure",
"evidence": "14 addresses on northgatedata.com in corpora published since 2025" }
],
"incidents": [
{ "date": "2025-06-11", "type": "disclosed_breach",
"source": "vendor_published_notice", "scope": "support ticket metadata" }
],
"dependencies": [
{ "provider": "Example Cloud", "role": "hosting", "basis": "dns_and_asn" },
{ "provider": "Example Identity", "role": "sso", "basis": "login_redirect" }
],
"change_events_30d": 3,
"caveat": "External signals describe internet-facing hygiene only and correlate imperfectly with internal security practice."
}Where the data comes from
| Certificate transparency logs | Public issuance records across the vendor's domains — open data, no vendor involvement needed |
| Public DNS and email authentication records | Ordinary resolution of records the vendor publishes deliberately |
| Passive DNS history | Licensed historical resolution data for detecting abandoned and changed infrastructure |
| Public breach disclosures and regulatory notices | Vendor notices, regulator publications and credible reporting, each cited with its source |
| Leaked credential corpora | From a provider whose terms permit this use; many restrict it, and the restriction is checked before the build |
| Vendor-supplied evidence and authorised checks | Where the vendor consents, questionnaire responses and authorised active checks can be attached to the same profile |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Authorisation gating: active checks run only against vendors that have granted it in writing, and every profile states which mode produced it
- Passive observation by default, built on data the vendor publishes or that is a matter of public record, with no probing of vendor infrastructure absent consent
- Component scoring kept separate rather than collapsed into a single grade, because a buyer needs to know whether the problem is email policy or expired certificates
- Attribution discipline on domain ownership — misattributing a shared-hosting neighbour's findings to a vendor is the most common and most damaging error in this category
- Change detection on normalised snapshots, so the alert fires on degradation rather than on routine certificate rotation
- Fourth-party inference from DNS, ASN and redirect observation, reported with the basis so a wrong inference can be corrected
- Calibration work stated honestly: where you can share your own incident history, we measure whether the score has any predictive relationship to it, and report the answer either way
- A machine-readable scope statement on every profile listing what was not observed, so downstream reporting cannot silently imply full coverage
What it changes for the business
Continuous visibility between assessments
Daily refresh fills the gap that an annual questionnaire leaves open for eleven months.
Prioritised assessment effort
Degradation signals point the formal review process at the vendors where something actually changed.
Concentration awareness
Fourth-party mapping shows how many critical vendors sit on the same hosting or identity provider.
Defensible monitoring record
Dated findings with evidence and a stated scope are what an auditor or insurer asks to see.
How it fits into your product
How it embeds
- Vendor registration from your existing GRC inventory, with domains resolved and confirmed during onboarding
- Posture profiles pushed into your vendor risk workflow alongside questionnaire records rather than replacing them
- Webhooks on degradation and new incidents, routed to the relationship owner
- Portfolio endpoints for concentration and tier-weighted reporting to a risk committee
- White-label output for platforms reselling monitoring to their own customers
- An authorisation workflow so a cooperating vendor can upgrade their own profile to include active checks
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you assess a vendor without their permission?
Passively, yes — and only from what is already public. Certificate logs, published DNS records, breach notices and regulatory filings are open information, and reading them is not an intrusion into the vendor's systems. Anything active — port checks, service probing, authenticated testing — requires the vendor's written authorisation, which the data model enforces. A profile always states which mode produced it, so a passive-only assessment cannot be mistaken for something more thorough.
How well does an external score predict an actual breach?
Imperfectly, and anyone claiming otherwise is selling. External hygiene correlates with engineering discipline, which correlates loosely with security outcomes. But the controls that most often fail — access review, privileged account monitoring, network segmentation, offboarding, third-party access — are invisible from outside. A vendor can score well externally and be badly exposed internally, and the reverse happens too. Where you can share your own incident history we will measure the relationship rather than assert one, and if the score turns out not to predict anything useful for your portfolio we will tell you.
Can this replace our questionnaire programme?
No, and we would argue against trying. Different coverage, different purposes. Questionnaires reach internal practice and contractual commitments; external monitoring is current and continuous but shallow. The useful combination is monitoring between assessments, with degradation signals deciding which vendors get assessed sooner. If the goal is to cut assessment cost by deleting the questionnaire, this is the wrong purchase.
What if you attribute the wrong assets to a vendor?
It happens, and it is the error with the worst consequences — an unfair finding in a vendor review damages a commercial relationship. Domain ownership is confirmed during onboarding rather than inferred from a name, shared-hosting neighbours are excluded by design, and every finding names the asset so the vendor can dispute it. We would also expect you to give vendors a route to contest a profile, and we build the correction path to support that.
Is leaked-credential data usable in a commercial service?
Sometimes. Several providers of breach corpora forbid redistribution or commercial reuse outright, and some jurisdictions add data protection constraints on processing credentials belonging to identifiable people. We check the licence of each source during discovery and design around the ones that do not permit your use, including dropping the component entirely if nothing permissible covers it.
Related blueprints
Domain Security Monitoring API
Continuous passive monitoring of DNS configuration, certificate expiry and externally visible services for domains you are authorised to watch.
Vulnerability Prioritisation API
Ranks known vulnerabilities by what they actually mean for a specific estate, combining exploitability, exposure and asset importance.
IP Reputation Intelligence API
Proxy, hosting, bot and abuse indicators for any IP address, served as a lookup your product can call on every request.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.