Keys and origins

GraveMint partner keys are invite-only. Request a key with the collections you plan to integrate and the origins where your application will run.

The three classes

Class	Prefix	Use	Restrictions
Publishable	gm_pub_	Browser applications	Registered origins and collection scope
Secret	gm_live_	Servers and MCP clients	Collection scope; keep the key private
Sandbox	gm_test_	Browser development on test networks	Registered origins, collection scope and test networks only

Use the prefix to identify a key's class when configuring an application or contacting support.

Publishable keys

A publishable key is designed to appear in a browser bundle. The API checks its registered origins and collection scope on each request. Sandbox keys add a test-network restriction.

Origin checks are browser access controls; they do not make a publishable key a secret. Keep its scope limited to the collections your integration needs.

Server keys

Store gm_live_ keys in server environment variables, such as GRAVEMINT_API_KEY. Variables with public build prefixes, including NEXT_PUBLIC_, VITE_, REACT_APP_ and EXPO_PUBLIC_, can be included in browser bundles and must not contain a server key.

Use a server key for backend calls. Publishable and sandbox keys require a matching Origin header, which a server request does not normally send.

Registering origins

Register each origin that will make browser requests:

• Production, such as https://yourdrop.io.
• The www hostname as well, if it serves your application.
• Staging and local development origins, including their ports.
• Each preview hostname, or a fixed preview hostname used across builds.

Origins match exactly. An origin consists of the scheme, host and port, so HTTP and HTTPS are separate origins. Wildcard preview domains are not supported.

Scope

A key grants access to specific collections. A request outside that scope returns 403 COLLECTION_NOT_IN_SCOPE, whether or not the requested collection exists. A key with no assigned collections does not grant collection access.

Collection scope applies to reads as well as mint operations.

Rate limits

Operation	Limit	Scope
Reads	600/min	Per IP
prepare and execute, combined	60/min	Per key
Collection prepare	30/10s	Per collection, shared with gravemint.io

A single mint normally uses one prepare and one execute request. Both count toward the same per-key limit, and the collection limit also applies. Handle 429 responses using Retry-After; see SDK retry behavior for the distinction between reads and transaction submission.

Key rotation

If a server key is exposed, request revocation and replace it. Revocation prevents further use; it does not reverse completed mints.

For a planned rotation, issue the replacement, update the application, then revoke the old key after confirming the replacement works.

Sandbox keys

Use a gm_test_ key with a collection on a test network. Sandbox keys return SANDBOX_KEY_ON_MAINNET on production chains; production keys return LIVE_KEY_ON_TESTNET on test networks. The API reference uses a sandbox key scoped to a devnet collection.