Once you have finalized your project, the finalized entries will become visible to the API. Pending entries are ignored (unless they were finalized before), so if you end up making manual changes to entries after finalizing, make sure to apply the pending changes by finalizing again. This is important to remember!

📘

Want to learn how to use the API?

Check out our API Reference! Teams can create API keys to be used across their multiple projects.

Initial setup

To set up your API, head on over to the API keys tab of your team. If you will be using the Attestations API on your minting frontend, we highly recommend that you configure the allowed origins for your API key. Setting this deters unknown origins from using your API key. It's not foolproof, but provides a reasonable measure of protection against API key abuse.

If you're using this API on your backend, you can optionally add allowed IP ranges as well for extra security.

Read more about API keys and authentication in the reference section.

Digital signatures

Updating eligible entries

You can update the list of eligible entries that can receive valid digital signatures at any time in the Signatures subtab of under the Developers section.

For example, you can progress from the winners-only stage to the winners-and-waitlist stage by checking both Selected (Won) and Waitlist under Allowed statuses. Signatures will immediately be available via the API for the addresses on the waitlist (as well as the winners).

Merkle proofs

Generating a tree

🚧

Please Note!

There's a limitation of 10k addresses per Merkle tree for teams.

If you must support more addresses, we suggest that you implement digital signatures instead. Digital signatures scale well and is more flexible in supporting changes to the set of addresses in the allowlist.

Unlike digital signatures, which reflects changes in finalized entries automatically, Merkle trees are immutable and new trees must be generated when you want new changes to be reflected via the API.

This is because the root hash of the Merkle tree changes when the set of included addresses changes, and because the root hash for a given tree must be stored on the smart contract, we cannot automatically update the Merkle tree since the root hash must be kept in sync.

You can generate new Merkle trees in the Merkle trees subtab, and you can choose which addresses to include in each tree by their status.

Setting the active tree

Teams can generate up to 3 trees per project. However, the API will only serve proofs against the "active" tree. Only 1 tree can be active at a given time. You can change the active tree at any time in the Merkle trees subtab.