Environment Variables
There are a number of environment variables you can change, these act as your config.
As noted in the previous section these are the required environment variables required to successfully deploy.
- HEDERA_NETWORK
- HEDERA_ACCOUNT_ID
- HEDERA_PRIVATE_KEY
- API_SECRET_KEY
- ENCRYPTION_KEY
The HEDERA_ENVIRONMENT is case-insensitive but when lower cased it must map to either, testnet, previewnet or mainnet.
If there is an invalid value the client will automatically throw the error.
Network from environment 'x' could not match for any hedera network. Change your 'HEDERA_NETWORK' environment variable to either: "testnet', 'previewnet' or 'mainnet'
Your scheduled test suite will also expose this configuration issue.
The variables HEDERA_ACCOUNT_ID and HEDERA_PRIVATE_KEY can be found in your hedera account after registration.
The API_SECRET_KEY is securely generated by you and it acts as your authentication key into your REST API.
The ENCRYPTION_KEY is a 32 length string acts as your secret for doing any kind of permissioned action in your app while ensuring that private keys don't touch your primary application for storage purposes. For testing you may generate a key with any key generator like this from GCS, however for production it is recommended that you generate it locally.
Conceptually you may generate custodial Hedera accounts on behalf of your users then assign tokens, there is a balance between non-custodial (Hashconnect) and custodial solutions dependent on:
- Your experience with Blockchain, Hedera, or DLT technology
- The needs of your users, is there dollar value connected to tokens or accounts
- Whether your use of Hedera is primarily for logging and provenence
- Stage of application development, do you need something that is quick to market to test for user feedback?
These variables are completely optional and aren't required but they unlock additional capacity for validating an installation of a client, webhook functionality, and security.
- API_URL
- WEBHOOK_URL
- HIDE_STATUS
- NFT_STORAGE_TOKEN
- MIRROR_NODE_URL
If you want to use our NFT flow functionality for the complete management of NFT over an API for the creation, minting, metadata generation, and advanced transfer feature you need both the NFT_STORAGE_TOKEN and MIRROR_NODE_URL set.
The API_URL variable is exclusively used by Github Actions to automatically check the status of a deployment, this isn't required to be part of the vercel deployment.
The WEBHOOK_URL variable provides a method for all timestamped consensus responses to be sent to your server, allowing you to set up an asynchronous flow for broadcasting messages and not having to wait for consensus timestamps.
Using an asynchronous consensus flow enables new messages to be broadcast to hedera via your client in the 150-200ms range instead of waiting for the full 3-5 seconds for response finality when processed linearly.
The HIDE_STATUS variable provides the ability to hide the publicly available status screen that describes the state of your deployment, by default this status screen will be displayed.
Information of the current status of the deployment.
Last modified 1yr ago