Authentication and consent

vibe.market is an experimental protocol. Review the Terms. Never ask users to sign a different message while describing it as harmless sign-in.

API key required

For agent workflows, use the canonical skill.md. It is our single agent instruction file; this page supplies the authentication reference. Send your registered Vibechain key in the API-KEY header on every documented JSON/API request, including public-data reads, uploads and website discovery. Both build.vibechain.com/api/vibemarket2 and the website’s vibechain.com/api/vibemarket2 JSON gateways enforce it. The original Classic HTTP API is not part of the published developer surface. Create a developer key with the shared registration endpoint:

curl --fail-with-body https://build.vibechain.com/apikey/create \
  -H 'Content-Type: application/json' \
  --data '{"email":"developer@example.com","description":"My market integration"}'

Replace the email and description with yours. Registration is limited to one request per minute per IP. A successful response uses HTTP 200 with success: true, code: "201", and key; check success, not just HTTP status. Do not register a key on each page load.

curl --fail-with-body https://build.vibechain.com/api/vibemarket2/runtime/versions \
  -H "API-KEY: $VIBECHAIN_API_KEY"

Limits

Independent budget	Normal key, per 60 seconds
GET/HEAD reads	100 requests
POST/PUT/DELETE and other writes	25 requests
GET stream connections/reconnections	10 connections

Budgets are keyed by API key across routes, not by wallet or spoofable client IP. The existing approved key multiplier scales each budget. Counters currently reside on each backend replica, so these are per-replica limits, not a guaranteed fleet-wide billing allowance. Inspect RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, RateLimit-Policy and Retry-After; back off with jitter on HTTP 429. Missing/malformed keys return 401 API_KEY_REQUIRED; unrecognized/disabled keys return 401 API_KEY_INVALID. Lookup outages fail closed with 503. The shared key resolver retains its existing cache behavior; key changes are not guaranteed to propagate immediately. The first-party clients automatically use the existing shared application key and its very high approved multiplier. It is public client configuration, not a secret or authentication factor. Its practical quota exemption does not remove action-specific wallet signatures, payload limits, concurrency limits, provider-work budgets, moderation or wallet-write quotas. Integrators should obtain their own keys, not rely on the website’s key. The website gateway reserves the caller’s quota before reading cached data or forwarding through the shared application key. GET /api-key?bucket=read|write|stream returns 204 on successful admission and consumes one request from that budget; it is not an unlimited validation endpoint. Use the underlying data request instead of probing admission repeatedly.

Streams and publicly renderable assets

Failed key attempts have an additional 300-per-minute/IP guard before database work. A valid API key does not accumulate failures merely because a wallet-authorized or application operation is rejected. This guard is separate from developer read/write/stream quotas. Native EventSource cannot set headers. Only the exact GET /runtime/{version}/stream route also accepts ?apiKey=...; an API-KEY header takes precedence. Do not use query credentials on other routes or log/share stream URLs. API keys do not authorize private wallet actions. The website’s narrow NFT metadata, artwork redirects and generated SVG URLs remain publicly renderable for wallets, crawlers and <img>. The website supplies its app key for backend lookups. Direct backend metadata/artwork API calls still require your key. HTML pages and static images/audio do not require an API key. Provider event webhooks remain independently authenticated with their raw-body HMAC, and OPTIONS preflight does not return consumer data.

Wallet-signed creator actions

An API key identifies your integration and its quota; it does not authorize a creator action. POST /releases also requires a fresh, action-specific wallet signature with replay protection. Do not sign arbitrary JSON or reuse a transaction signature. The service validates the normalized action and its exact signed JSON order. Build the action from the published request schema, preserve the field order shown there, lowercase the wallet, use a fresh nonce and use a future Unix-millisecond expiry no more than five minutes away. For releases, the message is:

Vibe Market 2 — offchain release catalog
Wallet: {lowercaseAddress}
Nonce: {nonce}
Expires: {expires}
Action: {JSON.stringify(parseAction(action))}
This signature cannot launch a pool or spend tokens.

This signed HTTP action changes only the offchain release catalog. It cannot launch a pool, approve allowances, move funds or perform any other blockchain transaction.

vibe.market

vibe.market Classic

Company

API key required

Limits

Streams and publicly renderable assets

Wallet-signed creator actions

​API key required

​Limits

​Streams and publicly renderable assets

​Wallet-signed creator actions

API key required

Limits

Streams and publicly renderable assets

Wallet-signed creator actions