This page explains fetching accounts. Accounts are stored and fetched as the BitBadgesUserInfo interface. Visit the SDK docs for lots of useful functions for dealing with accounts.
Response details are confined to the request parameters passed in, so this means that merging responses with previous responses needs to be handled. To make this easy, we have exported helper functions that do this behind the scenes, or you can add a new response with the .updateWithNewResponse().
We will return the address corresponding to a user's preferred chain via address. This will match the chain returned in chain. See the algorithm for deftermining "native" chain in the Concepts section. We also return each equivalent address to their native address via: btcAddress, solAddress, ethAddress, and bitbadgesAddress.
Note that solAddress may be blank if we do not have adequate information. This is because Solana addresses can only be converted from and not to.
NSFW / Reported
NSFW or reported accounts will be flagged with the nsfw or reported properties. Everything is still fetched as normal with typical requests, and it is up to you to do what you want with these accounts.
Usernames and Avatars
username will be the user's BitBadges username that they have set. In a similar manner, profilePicUrl will be the user's pofile pic set on BitBadges. We leave external services like ENS images / names up to you to implement as those are out of scope for our API.
Sequences / Account Numbers
sequence and accountNumber will be the sequence (nonce) and accountNumber for the BitBadges blockchain. These are used for generating and signing transactions. publicKey is also provided.
$BADGE vs Badge Balances
The balance field is for $BADGE balance, whereas the collected array is an array of balance documents for collected badges.
Custom Pages, Watchlists, Hidden
Each profile will return their custom pages to be displayed on their portfolio: customPages. These are pages where the user has grouped together lists or badges and designated them to be displayed together on a page on their profile with a title and description.
Watchlists (watchlists) follow the same interface but are for user watchlists. They are not to be displayed publicly on the profile but are rather a way for a user to keep track of badges.
Hidden badges (hiddenLists and hiddenBadges) are similar, minus the title and description. These are badges that should be hidden from a user's portfolio. If they are hidden, we will hide them from standard search results.
Alias
The alias field denotes whether this is an alias address for a list (address list) or a collection. If it isn't, this will be blank.
Views / Paginations
The colleuserction interface uses a view system with paginations + bookmarks.
Views have a base viewType describing the query type and a unique viewId for identification. Each request you will pass in a bookmark obtained from the previous request (pass in '' for the first request). This will fetch the next 25 documents for that view. Once no more docs can be fetched, the returned hasMore will be false.
The account interface also supports different filtering options. Make sure that all fetches with the same viewId specify the same filter options.
//An array of views to fetch viewsToFetch?: {//Unique view ID. Used for pagination. All fetches w/ same ID should be made with same criteria. viewId: string,//The base view type to fetch. viewType: AccountViewKey,//If defined, we will filter the view to only include the specified collections. specificCollections?: BatchBadgeDetails<NumberType>[];//If defined, we will filter the view to only include the specified lists. specificLists?: string[];//Oldest first. By default, we fetch newest oldestFirst?: boolean;//A bookmark to pass in for pagination. "" for first request. bookmark: string }[];
The user interface supports the following base viewType values.
'transferActivity' : Fetches latest transfer activity documents for the user.
'listsActivity': Fetches latest list activity documents for the user
'reviews': Fetches latest reviews for the user
'badgesCollected': Fetches badges owned by the user
'createdBadges': Collections / badges that the user has created
'managingBadges': Collections / badges that the user is managing currently
'allLists': Fetches lists that the user are explicitly defined on (whitelist or blacklists)
'whitelists': Fetches lists that the user are explicitly included (i.e. whitelists)
'blacklists': Fetches lists that the user are explicitly excluded (i.e. blacklists)
'createdLists': Lists that the user has created (excludes private lists)
'publicAttestationProofs': Public attestation proofs that the user has created
The following require authentication:
'latestClaimAlerts': Latest claim alerts
'siwbbRequests': Authentication QR codes for the user
'privateLists': Private lists created by the user
'createdAttestations': Attestations that the user has created
'receivedAttestations': Attestations that the user has received
'attestationProofs': Attestation proofs that the user has created
And so on. Remember, each response is confined to its request, so it will fetch the next 25 docs, but you have to append it to the previous 25 docs as explained above.
The ids returned in each view will correspond to the _docId field in its corresponding array (e.g. activity for the 'latestActivity' view). You can fetch the entire view with the helper functions.