Skip to main content

​
Direct HTTP requests

Use one API key header:
New keys begin with mry_ (47 characters total). Dashboard keys contain 256 bits of random secret material, are stored as hashes, and are shown only when created. They have no expiry by default; optional expiry is supported when creating a named key. Guided agent setup uses a scoped, recoverable compact key so an authenticated user can copy setup again; its plaintext is never stored. Authorization: Bearer <API key> remains accepted for compatibility. Send exactly one credential header. Multiple copies of either header, or both X-API-Key and Authorization, are rejected even if the values match. A malformed API key never falls back to browser-session authentication. Keys in query parameters are not supported.

​
Create and manage keys

Sign in at the dashboard with Google or a verified email address. Accept the current terms before creating a key. The dashboard creates one default key after acceptance; additional named keys are available for separate applications. Copy a new dashboard key when it is shown. It cannot be revealed again. If the creation response is lost, retrying the default-key request returns the same key metadata and no secret; it does not create another key. Create a named replacement and revoke the inaccessible key. The following routes require the signed-in human’s Firebase browser session. API keys cannot manage keys or accept terms. The guided setup route can recover its own eligible setup key after verifying the human browser session, current canonical terms and stored key hash. This does not enable reveal for ordinary dashboard keys. Setup also satisfies the initial default-key step, so opening the dashboard does not create another key. Legacy JWT credentials retain their prior verification and permissions. The legacy reveal route can only reveal eligible legacy credentials; it cannot reconstruct a new compact key.

​
Terms and licensed data access

Enrich, Search, and licensed parcel data require current terms acceptance. New keys bind earth.enrich, earth.search, and data.property.read grants to that account’s current acceptance receipt. Older keys do not acquire these grants when an account accepts terms; create a new key for the new APIs. The dashboard reads GET /v1/users/me/terms and displays the exact current document. Acceptance uses POST /v1/users/me/terms with version set to the returned required_version, plus the returned document_sha256 and document_url, plus accepted: true. The service returns the current earth-terms-v1 receipt. A stale or mismatched document is rejected. Accepting terms does not issue keys, grant money, or perform a purchase. Authorization is checked against the current account, credential, and receipt before licensed work and before returning saved licensed results. Revoking a key or disabling an account also blocks delivery of previously stored results. Existing keys retain access to their prior public-data operations. Paid operations also require the account’s current terms receipt and sufficient balance under its spending controls. A terms receipt never bypasses account restrictions.

​
Hosted MCP

Connect a supported client to https://api.mireye.com/mcp. The hosted service uses OAuth 2.1 with PKCE; clients discover the authorization endpoints automatically.
Complete browser sign-in. To use Enrich, Search, or licensed parcel data, accept current terms and explicitly approve licensed access for the same signed-in account. An existing OAuth session needs reauthorization. Token refresh preserves its original grants and never adds licensed access. OAuth tokens issued for /mcp are not accepted as direct /v1/* API keys. Use a dashboard key for direct HTTP requests. Local device-code issuance is retired. Device start, approval, and polling routes return HTTP 410. Existing local adapter connections should be replaced with the hosted connection; there is no local login flow to finish.

​
Public endpoints

Health probes, the public field and pricing catalogs, Swagger UI, and the OpenAPI schema do not require a key. Data requests require authentication even when the operation is free. Account management requires a human browser session.

​
Errors and limits

Authentication errors use the normal structured error response. A 401 indicates a missing, conflicting, malformed, expired, or revoked credential. A 403 can indicate unverified identity, account restrictions, missing current terms, or the need to reauthorize licensed access. An unavailable authorization or terms store fails closed; retry after service recovery. Rate limits apply to free and paid operations. See pricing or GET /v1/meta/plans for current plan limits. Honor Retry-After on 429. Adding funds does not increase the active plan’s request rate.