Developer Documentation

Trust signal,
delivered as data.

A deeper look at how the RRSource API is planned to work — endpoints, auth model and response shape. In development, not yet live.

Planned endpoints

Four core operations.

In development — not live yet

GET /v1/reports/{bm_id}

Look up a single Reputation Record by ID.

POST /v1/search/bulk

Submit a batch of names or identifiers for bulk lookup — for vendor or candidate screening at volume.

POST /v1/webhooks

Register a callback URL to be notified when a record you follow changes.

GET /v1/reports/{bm_id}/verification

Read the verification tier and identity status for a record, separate from its behavioural content.

Auth & structure

Planned to be boring, on purpose.

Bearer-token auth

Planned as standard API-key / OAuth2 bearer-token auth, scoped per organisation — nothing bespoke to learn.

Tiered rate limits

Rate limits scale with plan tier, same as most enterprise APIs — exact figures will be published once the API opens up.

Illustrative response shape — not a live endpoint

rrsource-api (planned)
GET /v1/reports/RR-10234
{
"bm_id": "RR-10234",
"entity_type": "individual",
"rr_score": 742,
"identity_verification": { },
"behavioural_history": [ ],
"resolution_status": "resolved"
}