A reliability record a business owns

The problem

B2B reputation is even more trapped than a person’s. A supplier with a decade of on-time delivery has references scattered across a dozen buyers’ inboxes and nothing portable to show the next one.

The signals that do exist (star ratings, directory listings, self-written company profiles) are gameable, unauditable, and often measuring the wrong thing.

And the obvious shortcut is one no fair system should take: a public register of a business’s customers or no-shows is a consumer blacklist, exactly the thing to refuse to build.

The solution

• Register a business as a subject, one of your external ids, with declared facts (trading name, industry, jurisdiction). It writes no events and touches no score; it simply labels a subject you report outcomes for.
• Outcomes flow through the same ingestion path a person uses: report them to the ledger, or use the stronger confirmation flow where the counterparty business affirmatively confirms. An outcome only counts as evidence when a distinct business confirmed it; naming yourself as your own counterparty is recorded but never confirmed.
• The record reports verification depth (confirmed ÷ total) and the number of distinct confirming counterparties (density), so one buyer confirming forty jobs never reads as forty buyers. The score is the identical deterministic formula: it is never an aggregate of the business’s employees’ personal scores, and no staff or customer data ever touches it.
• The business owns and presents its record the way a person does: a share token and a signed, offline-verifiable business-record credential, revocable at the published source.

How it works

Credda records outcomes between businesses. It holds no register of a business’s customers, patients or clients, and derives nothing from the people who work there, both stated in every business-record payload.

The API calls involved

• POST/api/v1/businessesRegister or update a business subject. Writes no events, touches no score.
• GET/api/v1/businesses/{id}Declared facts, current deterministic score, and confirmed B2B record.
• GET/api/v1/businesses/{id}/recordThe counterparty-confirmed record alone: evidence counts and verification depth.
• POST/api/v1/confirmationsPropose an outcome; a distinct counterparty business confirms it into the ledger.
• POST/api/v1/eventsReport a B2B outcome directly. An Idempotency-Key makes the write exactly-once.
• GET/api/v1/verify/{token}/business-recordPublic: resolve a business’s shared record and its signed credential. No key.

# Register a business subject (one of YOUR external ids)
$ curl -X POST https://api.credda.io/api/v1/businesses \
    -H "Authorization: Bearer $CREDDA_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{"userId":"acme_dental","controlledByReportingPlatform":false,
         "business":{"tradingName":"Acme Dental","industry":"Healthcare"}}'

# Read its deterministic score + counterparty-confirmed record
$ curl https://api.credda.io/api/v1/businesses/acme_dental \
    -H "Authorization: Bearer $CREDDA_API_KEY"
{ "subjectType": "ORGANIZATION",
  "score": { "finalScore": 78, "scoreBand": "Good" },
  "businessRecord": { "confirmedOutcomes": 34, "verificationDepth": 0.87,
                      "distinctConfirmingCounterparties": 19, "onTimeRate": 0.94 } }

Full request and response shapes are in the API reference.

Start building