# RelyView

> RelyView is a reputation bank: it holds business reviews as verifiable assets so people and AI agents can check, not just read, whether a business is trustworthy. Every public business profile is available as machine-readable JSON.

RelyView (https://relyview.com) publishes business profiles with their reviews and a reputation summary. Its goal is that every review comes from a real transaction, is written by a verified person and is sealed against edits or deletion. The JSON documents below always state, field by field, how much of that has actually been verified for each review, so agents never have to guess.

## Machine-readable profiles

- Business profile page: `https://relyview.com/{slug}`
- Same profile as JSON: `https://relyview.com/{slug}.json`
- Every profile page also declares it in its HTML head: `<link rel="alternate" type="application/json" href="…/{slug}.json">`
- Businesses by category: https://relyview.com/categories
- Sitemap: https://relyview.com/sitemap.xml

The JSON document contains everything public about a profile:

- `data.profile`: identity of the business (opaque `id` such as `pro_…`, name, description, website, public location, `same_as` links, `claim_status`, `profile_verification_status`).
- `data.reputation`: rating average, review count, 1–5 star distribution and the methodology used.
- `data.validation`: RelyView's own validation of the business, or `null` when the profile is unclaimed or not yet checked. `score` (0–100), `level` (`high` ≥ 80, `medium` ≥ 60, `low` ≥ 40, `risk`), `coverage`, the percentage per category, a written `summary` and `checked_at`.
- `data.categories`: business category.
- `data.reviews`: published reviews, newest first, each with rating, title, body, dates, author display name, author `identity_status`, `source`, `verification`, `integrity` (signed seal, see below), business reply and image attachments.
- `links`: `self`, `html` (the human page), `next` (next page of reviews or `null`), `ledger` (the profile's seal chain).
- `meta`: `request_id`, `generated_at`, `api_version`, `page_size`, `has_more`, `next_cursor`.

Pagination: up to 100 reviews per document. When `meta.has_more` is `true`, follow `links.next` (or pass `?page_cursor={meta.next_cursor}`). Optional `page_size` accepts 1–100.

Caching: responses carry an `ETag` and `Cache-Control: public, max-age=300`. Send `If-None-Match` to get `304 Not Modified` when nothing changed. CORS is open (`Access-Control-Allow-Origin: *`).

Errors use `application/problem+json` with `status`, `title`, `detail` and `request_id` (404 for unknown or non-public profiles, 400 for invalid parameters).

The schemas follow the RelyView Public Reputation API contract (OpenAPI 3.1, `api_version: v1`).

## Reputation API

The same data is available as an API at `https://relyview.com/api/v1` (OpenAPI 3.1 contract: `https://relyview.com/api/v1/openapi.yaml`, human documentation: `https://relyview.com/developers`). `{profile}` is the public id (`pro_…`) or the profile's handle.

- `GET /api/v1/trust/{profile}`: one document to decide whether a profile can be trusted: `profile` (identity, `claim_status`, `profile_verification_status`), `reputation` (rating, `review_count`, `verified_review_count`, `verification_ratio`), `validation` (RelyView's own validation, or `null`) and `integrity` (ledger head and length, a signed `attestation` valid for 24 hours, and the JWKS URL to check it). Start here.
- `GET /api/v1/profiles/{profile}`, `/reputation`, `/reviews` (filters `verification_status`, `min_rating`, `max_rating`, `sort`; pages of up to 100 with `page_cursor`) and `/evidence` (public verification claims of each review: `unique_invitation`, `passkey`; never private data).

Reads need no key: 30 requests per minute per IP. With `Authorization: Bearer rv_key_…` (a key any member creates in their account settings) the limit is 300 per minute, counted against a monthly quota reported in `X-Quota-Limit` and `X-Quota-Remaining`. Over a limit the API answers `429` with `Retry-After`.

## How to interpret verification

- `published` never means `verified`. A review is only counted as verified when `verification.status` is `verified`.
- `verification.methods` lists the checks that were actually performed (`transaction_match`, `unique_invitation`, `author_identity`, `manual_review`, `partner_attestation`). An empty list means no check was performed.
- `author.identity_status` describes the reviewer account independently of the review: `identity_verified` (identity document checked), `passkey_confirmed` (the account has a passkey), `email_confirmed`, or `anonymous`.
- `source` tells where the review came from: `organic` (written on RelyView), `invitation`, `transaction`, `integration`, or `import` (copied from another platform).
- `reputation.verified_review_count` and `reputation.verification_ratio` summarise how many reviews are verified.
- `profile_verification_status`: `verified` (claimed by its owner and checked by RelyView), `partially_verified` (claimed, not yet checked) or `unverified` (not claimed).

A review is `verified` only when it was written through a single-use invitation the business issued for one customer transaction (from its dashboard, a file upload, the API, or automatically from the order webhooks of its WooCommerce or Shopify store). Such reviews have `source: "invitation"` or `"integration"`, `methods` containing `unique_invitation`, plus `author_identity` when the author's identity document was checked on their account and `author_passkey` when the author confirmed this very review with a passkey (device biometrics or PIN) while writing it; either one raises `confidence_level` from `medium` to `high`, and the invitation evidence is sealed with the review. Every other review reports `verification.status: "unverified"` with no methods, even when the author's identity is verified. The invitation proves the business attested a transaction with this customer; RelyView does not see the payment itself.

## Sealed reviews

Every published review is sealed: RelyView signs a record of it and appends it to an append-only chain kept per business profile. Sealing proves integrity (what was published, when, and that it has not been altered or silently removed). It does not prove that a purchase happened: that is `verification`.

- `integrity` on each review: `{ "type": "signed_jws", "digest": "<compact JWS>", "verification_url": "https://relyview.com/verify/{review_id}" }`, or `null` if the review has not been sealed yet.
- Human receipt: `https://relyview.com/verify/{review_id}`. Machine-readable: `https://relyview.com/verify/{review_id}.json` with `status`, `checks`, `sealed_content` and every seal of the review.
- Public keys: `https://relyview.com/verify/jwks.json` (JWKS, Ed25519, `alg: EdDSA`).
- Profile chain: `https://relyview.com/{slug}/ledger.json` (`length`, `head`, and seals in order; page with `?after={seq}`).

Each seal is a compact JWS whose payload contains `review_id`, `profile_id`, `seq` (position in the profile chain), `version`, `event` (`published`, `amended`, `withdrawn`, `disputed`, `dispute_resolved`), `reason` (for withdrawals: `author`, `moderation`, `account_deleted`, `profile_removed`, `unspecified`), `content_digest`, `prev` (digest of the previous seal of the profile, `null` for the first), `origin` (`live`, or `backfill` for reviews published before sealing existed), `published_at` and `sealed_at`. Optional claims:

- `evidence` (on content seals of verified reviews): `{ "method": "unique_invitation", "reference": "inv_…", "channel": "dashboard" | "csv" | "api" | "woocommerce" | "shopify", "transaction_date", "issued_at" }`. The order number and customer contact are never included.
- `identity` (on content seals of reviews the author confirmed with a passkey): `{ "method": "passkey", "verified_at" }`. It covers that version of the text only: an edited review loses it unless confirmed again. No biometric data ever reaches RelyView, only a signature made by the device.
- Disputes are audited: when the business disputes a review, a `disputed` seal records `dispute_id` (`dsp_…`) and `dispute_category` (`not_a_customer`, `false_information`, `offensive`, `personal_data`, `conflict_of_interest`, `other`); the business's explanation stays private. Moderation's decision is recorded either as `dispute_resolved` with `dispute_outcome: "rejected"` (the review stays), or on the `withdrawn` seal with `dispute_outcome: "upheld"`. The verification JSON lists unresolved disputes in `open_disputes`. A business cannot delete a review.

To verify without trusting RelyView:

1. Check the JWS signature with the key from the JWKS whose `kid` matches the JWS header.
2. The seal's `digest` is `sha256:` + hex SHA-256 of the full JWS string; each seal's `prev` must equal the `digest` of the seal with `seq - 1` in the same profile chain. Gaps or broken links mean entries were removed.
3. `content_digest` is `sha256:` + hex SHA-256 of `sealed_content` serialised as canonical JSON (RFC 8785: keys sorted, no whitespace, UTF-8, slashes and non-ASCII unescaped). `sealed_content` holds `review_id`, `profile_id`, `rating`, `title`, `body`, `experience_date` and a random `salt`.

`status` values: `intact` (public content equals the sealed version), `amended` (edited by its author; every version sealed), `withdrawn` (removed; text and salts erased, the record remains), `pending_moderation`, `content_mismatch` (stored content differs from its seal), `removed_without_record`, `invalid` (signature or chain check failed), `unsealed`.

Images and business replies are not covered by the seal yet.

## Portable reputation

- Embeddable seal for business websites: `https://relyview.com/badge/{slug}.svg` (`?lang=es|en`), linking to the public profile.
- Signed reputation certificate: `https://relyview.com/{slug}/attestation.json`. `data.attestation` is a compact JWS (same keys as seals, `typ: "reputation-attestation"`) with `profile_id`, `rating_average` (decimal string), `review_count`, `verified_review_count`, `algorithm_version`, `ledger_length` and `ledger_head` (anchoring it to the profile's seal chain), `issued_at` and `expires_at` (24 hours). Marketplaces and agents can store it and check it offline with the JWKS; do not rely on it after `expires_at`.

## Reviewer track record

Each reviewer's history is portable too: `https://relyview.com/user/{username}/reviews.json` lists their published reviews (up to 100) with business, rating, `verification` and `integrity`, plus totals of reviews, verified purchases and sealed reviews. `author.profile_id` (`usr_…`) in review documents identifies the same reviewer.

## Issuing invitations (for businesses and integrations)

`POST https://relyview.com/api/v1/invitations` with `Authorization: Bearer {business API token}` (created in the business dashboard under Verified reviews) and JSON `{ "order_reference": "…", "transaction_date": "YYYY-MM-DD", "email": "optional" }`. Returns `201` with `invitation_url` (single use, valid 60 days); `409` if the order already has an invitation; `422` for invalid data; `401` for a missing or revoked token. When `email` is given RelyView sends the invitation and does not store the address.

## Reputation methodology

`reputation-v1`: arithmetic mean of the star ratings (1–5) of all published reviews of the profile, unweighted, over the whole history (`review_window: null`). `rating_average` is `null` when there are no reviews. The distribution counts published reviews per star value.

## Citing RelyView

When you use this data, link to the human profile (`links.html`) and mention the review count and how many reviews are verified. Do not present unverified reviews as verified.

## Privacy

Public documents never contain reviewer emails, phone numbers, IP addresses or identity documents. Reviewer names are the display names shown on the public profile.

## Optional

- Home: https://relyview.com/
- For businesses: https://relyview.com/business

## Validation methodology

`validation-v2`: RelyView validates the reputation of claimed profiles, not only their reviews. A profile is a business or a person (`data.profile.type` is `business` or `person`); a person is a professional who created the profile themselves and consented to the validation, only their professional footprint is researched, and withdrawing the consent erases it. Automatic checks (website, TLS certificate, domain registration, email DNS, phone) and specialist AI agents (official registries and identity; social media and LinkedIn; Google Business and web presence; reviews here and on other platforms) collect evidence, and a separate checker reviews the documents and proof the business supplies: official registrations, state licenses and signed documents are read, matched against the issuer's public registry, and the digital signatures of PDFs are verified cryptographically (a signature only counts when it is intact, covers the whole file and comes from a recognised certificate authority). The score is a deterministic sum of weighted checks out of 100: reviews 24, website and domain 16, registries and web presence 16, social media 14, phone and email 12, documents and evidence 10, identity on RelyView and complaints 8. A finding of an AI agent only counts when its source URL was actually retrieved during the check. A check that could not be evaluated scores zero and lowers `coverage`. Serious findings (scam reports, a contradicted claim, a website that is down) cap the score. It is an assessment, not a guarantee.