# Get Asset (empty name)

**GET /byron-wallets/{walletId}/assets/{policyId}**

Fetch the asset from `policy_id` with an empty name.

The asset must be associated with the wallet.



## Servers
- https://localhost:8090/v2: https://localhost:8090/v2 ()



## Parameters

#### Path parameters
- **walletId** (string(hex))
  
- **policyId** (string(hex))
  



## Responses
### 406: Not Acceptable

#### Body Parameters: application/json (object)
- **message** (string)
  May occur when providing an invalid 'Accept' header.
- **code** (string)
  

### 404: Not Found

#### Body Parameters: application/json (object)
- **message** (string)
  Occurs when requesting information about an asset which is not
involved in any transaction related to the wallet.

- **code** (string)
  

### 200: Ok

#### Body Parameters: application/json (object)
- **policy_id** (string(hex))
  A unique identifier of the asset's monetary policy. The policy
controls how assets of this kind are created and destroyed.

The contents are the blake2b-224 hash of the monetary policy
script, encoded in hexadecimal.

- **asset_name** (string(hex))
  The asset on-chain type which acts as a sub-identifier within a
policy. Although we call it "asset name", the value needn't be
text, and it could even be empty.

For policies with a single fungible asset item, asset name is
typically an empty string.

This value can be up to 32 bytes of arbitrary data (which is 64
hexadecimal digits).

- **fingerprint** (string)
  A user-facing short fingerprint which combines the `policy_id` and `asset_name`
to allow for an easier human comparison of assets. Note that it is generally
**not okay** to use this fingerprint as a unique identifier for it is not collision
resistant. Yet within the context of a single wallet, it makes for a (rather)
short user-facing comparison mean.

- **metadata** (object)
  In the Mary era of Cardano, UTxO may contain native assets. These
assets are represented on-chain by opaque identifiers which are
meaningless to end-users. Therefore, user-facing metadata
regarding each token must be stored off-chain, in a metadata
registry.

Token creators may publish metadata into the registry and client
applications can consume these metadata for display to end
users. This will work in a similar way to how it is done for stake
pool metadata.

- **metadata_error** (string)
  If there was an error fetching metadata from the server,
this will be set to one of `fetch` or `parse`, to indicate
the kind of error.



[Powered by Bump.sh](https://bump.sh)