Changelog

The distributor API's own address is now the one the interface document lists first, and the document's own download address moves with it. The address under the holder app stays in the document as the legacy way in: both answer the same calls, so an integration built on either keeps working.

The distributor SDK, version 0.1.1, now answers at the API's own address when a page connects without naming one, names that address in its example and in the sentences its refusals carry, and keeps every address that answered before answering the same calls, so pages already integrated keep working.

The registry companies read is callable: a distributor's key with the availability scope can now read the companies one registry holds, a page at a time, narrowing by country, ISIN or chain.

See: GET /v1/registry/companies.

A distributor can now record a benefit claim for a self-custody holder: the call stands on the challenge the wallet signed, and Yutai re-checks every rule at claim time, so an earlier eligibility answer never stands for one.

See: POST /v1/claims.

The claim challenge call is callable: a distributor's key with the claims.write scope can now ask for the one message a wallet signs before a claim, with the one-time nonce beside it.

See: POST /v1/claims/challenge.

The distributor SDK is at version 0.1.1: the connect door a page calls is now connectDistributorApi and the refusal class it throws is now DistributorApiRefusal. The old names still work for one release, with one warning in the browser console that names the new door, so pages already integrated can move when they are ready.

The planned holder-id reads were removed from the published interface: no route ever served them, and a distributor identifies a holder by wallet. The wallet eligibility read answers as before.

See: GET /v1/eligibility.

The eligibility read is callable: a distributor can ask which benefits one or more wallets reach.

See: GET /v1/eligibility.

The distributor SDK is at version 0.1.0: the script and one npm install both register the credential card, tier badge and benefits list elements, and the tags a distributor writes carry their types. The manifest beside the script pins the exact copy and its size.

The docs gained the API reference page: every call the distributor API serves, with its parameters, its answers and a curl to copy.

See: API reference.

The docs gained the webhooks page: what one delivery carries, when a failed delivery is tried again and how it is signed.

See: Webhooks.

The distributor API's first interface, v1, was released and frozen; its document described holder resolution by wallet, a holder's credential status and a holder's benefits list, none of which a route ever served, and the 9 October entry records their removal. A change that would break a distributor integrated against it waits for a new release.

The docs gained the verify a credential page: check a credential a holder handed you in your own browser, with nothing sent anywhere and nothing stored.

See: Verify a credential.

The docs gained the identifiers page: every identifier a distributor sends or reads, in one place.

See: Identifiers.

The docs opened with the credential card page: the planned embed, a live sample rendered by the element itself, and the attributes and tokens the card takes.

See: Credential card.

The distributor SDK shipped: one script tag loads it on a distributor page, and it registers the credential card element a distributor writes with plain HTML.