Changelog

The claim read at GET /v1/claims/{id} and the fulfilment poll at GET /v1/fulfilments now accept a key carrying the claims.read scope, so a distributor can read a claim and list the fulfilments waiting on its word without holding the claims write scope. A key carrying claims.write answers both calls exactly as it did.

The docs gained the MCP server page: how an AI agent connects to Yutai's public server with no key, the nine read-only tools, the two prompts and the four resources it carries, and the sixty calls a minute limit. Developer and holder access are not open yet.

See: MCP server.

The eligibility answer now names the lending protocol behind a token's split in its own source field, and it reads Euler positions beside Kamino, Jupiter and Morpho. The breakdown sentence names the protocol the units were read through, so a split no longer always says Kamino. The change adds one field and new location names. A token lent through two protocols answers one row per protocol, so a row's shares name that protocol's part of the token.

A new Claim a benefit guide walks the challenge, the claim, the claim read, its link reissue, the fulfilment list and its confirm in the order a claim runs, each with its key scope and its own sample.

See: Claim a benefit.

The Connect unlink call is now callable: a distributor's key with the connect.write scope can end one person's link by the external reference its create took, and the call answers with no body. An unknown reference, a reference that names no link and a reference another distributor linked all answer the same refusal, so no reference can be probed.

See: DELETE /v1/connect/links/{external_ref}.

The Connect outcomes read is now callable: a distributor's key with the connect.read scope can ask, for one person's external reference, whether the link stands, the day consent ends, and for each company the person holds whether they are also its customer and the benefits that opens. It answers outcomes, never purchases or balances.

See: GET /v1/connect/outcomes.

The docs gained the pagination page: how a page of a list is asked for, what its answer carries and how to move through a long list without losing your place.

See: Pagination.

The availability and eligibility answers now name every offer's scope and funder, and a distributor's own key also receives the live Yutai Plus offers scoped to it, each with the distributor's name, the reward tiers and, on the eligibility answer, the holder's streak toward the tier that asks days. A base offer still reaches every distributor, and a Plus offer reaches no other distributor and never the holder app.

Each token in the eligibility answer now carries three more facts: the security's ticker (null when the registry records none), the token's own symbol, and the chain's name in words. The change only adds fields; every field an existing integration reads keeps its name and its meaning.

The docs gained the Yutai Connect page: how a distributor opens the hosted link flow for one person, what the page reports back, and how to manage or end a link.

See: Yutai Connect.

The tier words in the distributor API documents, the distributor SDK and these docs now read Tier 1, Tier 2 and Tier 3. A page that still carries an old tier word is refused with a sentence naming the new words, and deliveries made before the change keep the words they carried.

The Connect session calls are now callable: a distributor's key with the connect.write scope can open one hosted session for a person, and a key with the connect.read scope can read it back by its id. The create answers the hosted page's address and the token's expiry, and the read answers the session as it stands.

See: POST /v1/connect/sessions, GET /v1/connect/sessions/{id}.

The docs gained the errors and limits page: every refusal status a distributor may read, what each one means and the read limits that apply.

See: Errors and limits.

The fulfilment calls are now callable: a distributor's key with the claims.write scope can read the credits that wait on its word and confirm one with its own reference for the credit. The confirm marks the fulfilment as credited, and a second confirm answers that it was already confirmed, so a retry never credits twice.

See: GET /v1/fulfilments, POST /v1/fulfilments/{id}/confirm.

The registry facts read and the availability read are now callable: a distributor's key with the availability.read scope can read the facts of the instruments it names and the benefits the companies behind a page of instruments offer in one market. Both reads answer what Yutai's own registry and catalogue hold, never whether a particular person reaches a benefit.

See: GET /v1/registry/instruments, GET /v1/availability.

The status read and the claim read are now callable: a distributor can ask which data domains stand in which mode before it holds a key, and a key with the claims.write scope can read back one claim it recorded by its id. The claim read answers its own state in words, from granted through waiting on the distributor's word to credited by the distributor.

See: GET /v1/status, GET /v1/claims/{id}.

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 claim link reissue call is now callable: a distributor's key with the claims.write scope can reissue the redemption link of a claim it recorded, and the answer carries a fresh link. Only the last link issued opens the claim, so an earlier link stops working, and a claim that stands rejected or was taken back answers a refusal.

See: POST /v1/claims/{id}/link.

The docs gained the benefits module page: how a distributor renders one person's benefits with the module element, the attributes it takes and the answers it draws.

See: Benefits module.

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 docs gained three pages: get started walks a partner from an account to a first key, the React page documents the components a React page writes, and the example exchange page shows a working claim flow.

See: Get started, React, Example exchange.

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 docs opened the pages most distributors read first: the quickstart walk and the overview of the ways to integrate, the account link and balance statement guides, the benefits list and tier badge pages, the security page and both worked examples, the wallet and the exchange.

See: Quickstart, Overview, Link a customer account, Sign a balance statement, Benefits list, Tier badge, Security, Example wallet.

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.