API Minting Docs
HomeTechnicalLegalWhitepaperCommunityMarketplace
Search
⌃K
Links

Collections

A Collection is a set of NFTs. We provide a flexible set of tools to help you create and manage your NFT Collections. ⚙️

Collection Creation Life Cycle

The process of creating a Collection involves three steps:
  1. 1.
    Creating a Collection Draft (off-chain)
  2. 2.
    Attaching assets (media & metadata files) to your Collection Draft
  3. 3.
    Finalizing your Collection Draft (on-chain creation of the Collection)
We will examine each step in detail, along with endpoints for minting NFTs and updating your collections.
For more information on types, refer to the "Referenced Types" article.

Collection Endpoints

Below are the endpoints available for Collection Drafts and Collections.
🌟 Create a Collection Draft
POST /collection-draft
Request Body:
A JSON object containing the following parameters:
  • contract_uuid (required; type string)
    • The contract to which this collection will be deployed
  • title (required, string, max length 256)
    • The Collection title, which will be inherited by its NFTs unless overridden.
  • description (optional, string, max length 1024)
    • An optional description for the Collection, which will be inherited by its NFTs unless otherwise overridden.
The following advanced parameters are also available:
  • public_mint_config (optional, PublicMintConfig)
    • Specifies the configuration for a mint where users will be minting directly from the NFT Contract and do not need to be whitelisted. If you plan on minting via API only, you should not set this property.
  • private_mint_config (optional, PrivateMintConfig)
    • Specifies the configuration for a mint where users will be minting directly from the NFT Contract and must be whitelisted. If you plan on minting via API only, you should not set this property.
  • bypass_mint_fee_accounts(optional, NearAccountId[])
    • NB: Contract owner and admins bypass mint fees by default, so there is no need to add them here.
  • initial_royalties (optional, Royalties)
    • Distribution of mint fees. Cannot total more than 95% (5% Few and Far initial royalty will be added before minting)
  • ongoing_royalties (optional, Royalties)
    • Royalties for secondary sales. Cannot total more than 100%.
  • allow_approvals (optional, bool)
    • If false, an NFT owner cannot grant approval to a 3rd party account (e.g. marketplace contract) to transfer the token on their behalf.
  • approvals_allowed_accounts (optional, NearAccountId[])
    • If present, listed accounts are the only accounts that can be granted approval by an NFT owner to transfer the token on their behalf.
  • approvals_denied_accounts (optional, NearAccountId[])
    • If present, listed accounts are the only accounts that cannot be granted approval by an NFT owner to transfer the token on their behalf.
  • allow_transfers (optional, bool)
    • If false, an NFT owner cannot transfer their NFT to a new owner (for devs familiar with contract methods: calls to nft_transfer, nft_transfer_call and nft_transfer_payout will result in a useful error message).
  • transfers_denied_accounts (optional, NearAccountId[])
    • If present, listed accounts are the only accounts that NFTs cannot be transferred to. This could be used by the collection owner to prohibit the use of escrow marketplaces that avoid royalty payments.
201 Success Response body:
A CollectionDraft object (see “Referenced Types” article for details)
🌟 Get a Collection Draft
GET /collection-draft/{collection_draft_uuid}
🌟 Get all Collection Drafts
GET /collection-draft
🌟 Attach assets to a Collection Draft
POST /collection-draft/{collection_draft_uuid}/asset-bulk
content-type: multipart/form-data
Request Body Constraints:
  • Maximum request body size: 100MB
  • Maximum size per file: 1MB
Request Body:
FormData containing parts as follows:
  • Asset files (required): Media files for NFTs that will be minted in this collection. These parts should be named asset_file
  • Reference/Metadata JSON files (optional): Typically used to specify attributes for a given NFT. These parts should be named reference_file. Each Reference file should correspond to one Asset file (these associations are made in the assets_detail form part - see below). Each Reference file should follow the OpenSea Metadata Standard.​
  • Assets Detail (required): JSON-stringified array of AssetDetail objects, each representing one NFT asset and its optional corresponding JSON metadata. This part should be named assets_detail. Only one assets_detail part should be provided in the form data. Note the following AssetDetail object properties:
    • asset_filename (required, string): An asset_subtitle file with this name MUST be present in the form data, or a 400 response will be returned.
    • copies (required, integer)
    • reference_filename (optional, string): If present, a reference_subtitle file with this name MUST be present in the form data.
    • asset_subtitle (optional, string): The title of individual NFTs in this collection will be formatted as collection_title + asset_subtitle (optional, string): e.g. “My Collection: Gold Edition” where “My Collection” is the collection_title and “: Gold Edition” is the asset_subtitle. In the asset_subtitle, you can reference the following values, which will be inserted into the NFT title at view time:
      • $TOKEN_NUM: The number of this token in the sequential order of minting, starting at 1 (e.g., the 2nd token minted in a collection would have a TOKEN_NUM of 2.)
      • $TOTAL_NUM: the total number of copies for this collection)
EXAMPLE assets_detail string:
'[{"asset_filename":"0.png","copies":10},{"asset_filename":"1.png","reference_filename":"1.json","copies":10,"asset_subtitle":" - Gold"}]'
A collection created with this assets_detail string would contain 20 copies in total. Ten copies would use asset file 0.png with no JSON and no NFT subtitle, and the other ten copies would use the asset file 1.png with the 1.json reference file and an NFT subtitle of “ - Gold”.
cURL Request Example:
curl --request POST \
--url https://testnet.fewfar.com/api/v1/collection-draft/{YOUR_COLLECTION_DRAFT_UUID}/asset-bulk \
--header 'Authorization: Api-Key {YOUR_API_KEY}' \
--header 'Content-type: multipart/form-data' \
--form 'asset_file=@/Users/username/path/to/asset/file.png' \
--form 'assets_detail="[{\"asset_filename\":\"file.png\",\"reference_filename\":\"file.json\",\"copies\":10}]"' \
--form 'reference_file=@/Users/username/path/to/reference/file.json'
​
201 Successful Response body:
An array of CollectionDraftAsset objects (see “Referenced Types” article for details)
🌟 Finalize a Collection Draft (publish on-chain)
POST /collection-draft/{collection_draft_uuid}/finalize
NB: A successful call to this endpoint will use funds from your integration wallet to create the new collection on-chain.
Request Body: None
201 Success Response body:
A success response will contain the following properties:
  • message (string)
    • “success” if the action was successful
  • ipfs_result (IpfsResult)
    • Refer to the "Referenced Types" section for details
  • contract_address (string)
    • Address of the Smart Contract that contains this new Collection
  • near_collection (Collection)
    • As defined in FnF-007 Specification docs, the on-chain Collection contains a collection_id (int) property, which is the blockchain ID for the collection and is used within the NFT contract. It is not the same as the collection's UUID - contained in this response as collection_uuid, - which should be used in Few and Far API requests.
    • The on-chain collection_id can be used if you wish to prompt users through a direct mint flow using a client-side NEAR wallet integration, rather than an API call. You can direct the user to call nft_mint on your contract and pass this collection_id to the method call. See the "End User (non-API) Minting" section in the NFT API docs for more information.
  • collection_uuid (string)
    • UUID for the collection, for use in Few and Far API requests
  • tx_results (NearTransactionResult[])
    • Refer to the "Referenced Types" section for details. Contains the result of the collection creation transaction.
When a Collection Draft is finalized, it becomes a Collection which has been published on-chain.
🌟 Get a Collection
GET /collection/{collection_uuid}
🌟 Get all Collections
GET /collection
🌟 Update a Collection
PUT /collection/{collection_uuid}
Request Body:
A JSON object containing the following parameters:
  • title (optional, string, max length 256)
  • description (optional, string, max length 1024)
  • public_mint_config (optional, PublicMintConfig)
  • private_mint_config (optional, PrivateMintConfig)
  • bypass_mint_fee_accounts (optional, NearAccountId[])
  • initial_royalties (optional, Royalties)
  • ongoing_royalties (optional, Royalties)
  • allow_approvals (optional, bool)
  • approvals_allowed_accounts (optional, NearAccountId[])
  • approvals_denied_accounts (optional, NearAccountId[])
  • allow_transfers (optional, bool)
  • transfers_denied_accounts (optional, NearAccountId[])
200 Success Response body:
An updated Collection object: See the “Referenced Types” section for details.
🌟 Add Allowlist Accounts for Collection
PUT /collection/{collection_uuid}/allowlist-add
Request Body:
A JSON object containing the following parameters:
  • accounts (required, NearAccountId[], max length 500)
    • These are “allowlisted” accounts that can participate in the private mint. A maximum of 500 accounts can be added per call (this will be increased in the future).
200 Success Response body:
A success response will contain the following properties:
  • message (string)
    • “success” if the action was successful
  • tx_results (NearTransactionResult[])
    • Refer to the "Referenced Types" section for details. Contains a single NearTransactionResult.

🌟 Remove Allowlist Accounts for Collection
PUT /collection/{collection_uuid}/allowlist-remove
Request Body:
A JSON object containing the following parameters:
  • accounts (required, NearAccountId[], max length 500)
    • These are “allowlisted” accounts that should be removed from the allowlist. A maximum of 500 accounts can be removed per call (this will be increased in the future).
200 Success Response body:
A success response will contain the following properties:
  • message (string)
    • “success” if the action was successful
  • tx_results (NearTransactionResult[])
    • Refer to the "Referenced Types" section for details. Contains a single NearTransactionResult.
🌟 Clear Allowlist Accounts for Collection
PUT /collection/{collection_uuid}/allowlist-clear
Request Body: None
200 Success Response body:
A success response will contain the following properties:
  • message (string)
    • “success” if the action was successful
  • tx_results (NearTransactionResult[])
    • Refer to the "Referenced Types" section for details. Contains a single NearTransactionResult.
🌟 Check Allowlist Account (check if account is allowlisted for Collection)
PUT /collection/{collection_uuid}/allowlist-checkaccount
Request Body:
A JSON object containing the following parameters:
  • account (required, NearAccountId)
200 Success Response body:
A success response will contain the following properties:
  • is_allowlisted (bool)
    • Indicates whether the provided NEAR account is part of the collection’s allowlist.
Previous
Contracts
Next
NFTs
Last modified 3mo ago