Skip to content
GPU Finder

API access and migration

Check current access and connect with a verified account and API key.

Migrate an existing caller

The following steps apply when developer onboarding and keyed access are available.

  1. Open the developer portal, request a verification email and continue from its ten-minute sign-in link. Marketing subscriptions and unsubscribe/confirmation tokens are not account credentials.
  2. Create a labelled API key and save the one-time secret securely. Send it only as Authorization: Bearer in server-side requests.
  3. Start with one snapshot; check usage before restoring your polling schedule. A 90-call catalogue sweep exceeds a fresh Free allowance. Reuse results and poll only the models you need.
  4. If your recurring volume needs a higher allowance, request a temporary extension below and wait for its reviewed decision before assuming extra capacity.
# Supply GPUFINDER_API_KEY from your secret manager; do not paste it into history.
export GPUFINDER_BASE_URL="https://gpufinder.dev"
curl --silent --show-error --config - <<EOF
url = "${GPUFINDER_BASE_URL}/api/v1/snapshot?gpu=h100&count=1"
header = "Authorization: Bearer ${GPUFINDER_API_KEY}"
EOF

Before an active notice, no cutover date is announced. During a configured notice, this page, the developer guide, llms.txt, OpenAPI and keyless REST notice headers show the same date. Key requirements can take effect immediately once onboarding is ready. The Free plan remains available with a verified account and API key; no purchase is required. At cutover, a missing key returns JSON 401 invalid_credential with registration/migration links; verify, create a key and update the header to recover.

In legacy mode, the seven data routes keep keyless behavior and ignore bearer headers for metering; keyed usage is unavailable. In pilot mode, keyed traffic shares account usage and keyless data has a temporary exception. Invalid Authorization in pilot never falls back to anonymous access. After cutover, data and usage require keys. Documentation does not activate any mode.

Keep and replace keys safely

Keep secrets in your server’s secret manager. Never put them in query strings, URLs, logs, screenshots, public repositories, frontend code, browser storage or MCP tool arguments. Avoid verbose HTTP traces and command-line arguments containing secrets. The examples send a curl header through standard input.

The portal can create, rename, expire, rotate and revoke keys. Rotation immediately replaces and revokes the selected key; save the replacement once and update your server/client configuration. For a staged handover, create a separate key if a slot is free, update callers, then revoke the old key. Revocation takes effect for future admissions. If a secret is lost or leaked, revoke and replace it; it cannot be revealed again.

Request a temporary allowance extension

Free accounts receive 60 data operations per UTC calendar month, resetting on the first day at 00:00 UTC. The first partial month includes all 60; unused units do not roll over. Up to 3 active keys share one account allowance across REST and MCP. The default keyed account rate is 120 authenticated requests per minute, including invalid input and usage; effective limits appear in usage. Network and service protections can also apply.

Successful admission spends one monthly unit, including cache hits, empty results and later failures, timeouts or disconnects. Authentication, validation, rate and quota denials spend no monthly units; invalid authenticated input costs rate only. Every separate inbound retry is a new operation. Check usage after uncertain transport failures before deciding to replay.

Sign in at the developer portal and use “Temporary allowance extension”. Enter the requested total monthly volume (1–100,000) and your use case/polling schedule. One pending request is allowed. Submission does not grant quota; requests are reviewed and may be declined.

Check the portal for pending/approved/declined status and decision reason. Approved extensions show their allowance, effective date, expiry and review date. Extensions last at most ninety days and have review at least fourteen days before expiry. Used units are preserved; the effective allowance and expiry appear in the portal. An expired extension returns to the underlying allowance. No automatic approval, renewal, decision email or response-time promise is made.

Monthly exhaustion does not block signed-in key, usage or extension management, subject to their own controls. A bearer key cannot authorize account management. If the portal is unavailable or the account is disabled, contact hello@gpufinder.dev; never include your key or verification token.

Errors, backoff and usage recovery · MCP preview setup · OpenAPI JSON