INOKOMD DEVELOPER PLATFORM

Build with InokoMD API.

Integrate token market snapshots into dashboards, trading tools, research workflows, and portfolio interfaces using a consistent InokoMD response format.

Deployment status: This documentation defines the InokoMD API contract and includes a Worker implementation. The endpoint becomes reachable on your own Worker URL after you deploy worker.js and configure an API key. This static website alone does not host a live API service.

Platform overview

One InokoMD response format

InokoMD API provides normalized market-pair information for a token contract. It is designed for applications that need consistent fields for pricing, liquidity, volume, transaction activity, valuation, and pair metadata.

Capability	Response data	Typical use
Market price	USD price and 5m, 1h, 6h, 24h change	Token detail cards and price panels
Market depth	Reported liquidity in USD	Liquidity filters and pool comparison
Trading activity	Volume and buy/sell counts	Activity dashboards and market monitoring
Valuation	Market cap and fully diluted valuation when available	Token screening and comparisons
Pair metadata	Chain, pair address, creation time and market URL	Verification and market context

Market figures can be delayed, incomplete, or absent for newly created or unindexed pairs. Market data is not a contract audit and does not establish that a token is safe.

01 · Quickstart

Make your first request

Use the base URL assigned to your deployed InokoMD API Worker. Replace API_BASE_URL and INOKOMD_API_KEY with your own values.

GET/v1/token/{address}Bearer auth

curl --request GET \ "${API_BASE_URL}/v1/token/0x6982508145454Ce325dDbE47a25d4ec3d2311933" \ --header "Authorization: Bearer ${INOKOMD_API_KEY}" \ --header "Accept: application/json"

Successful response

{ "data": { "query": { "address": "0xa0b8...eb48" }, "pairCount": 1, "pairs": [ { "chain": "ethereum", "token": { "name": "Example Token", "symbol": "EXT" }, "priceUsd": 1.02, "liquidityUsd": 125000, "volumeUsd": { "h24": 42000 }, "marketCap": 850000, "fdv": 1200000 } ] }, "meta": { "requestId": "server-generated-id", "generatedAt": "ISO-8601 timestamp", "sourceStatus": "data_found" } }

Example note: the response above is a shape example, not a claim about the current market or a guaranteed pair count. Real fields and values depend on the token and upstream coverage.

02 · API console

Test your deployed InokoMD endpoint

Enter your Worker base URL and token address. If your Worker is deployed and configured, this console sends the request to InokoMD's /v1/token/{address} route.

InokoMD API base URL

API key

Token contract address

Examples:

Requests are sent only after you press Run request.

Only enter an API key on your own official InokoMD site and only if you trust the domain. The key is used for this request and is not saved by this page.

03 · Endpoint reference

Token market snapshot

GET/v1/token/{address}

Returns available market pairs associated with the supplied token contract address.

Path parameter	`address` — token contract address, URL encoded
Authentication	`Authorization: Bearer <API_KEY>`
Success	`200 OK` with normalized data and request metadata
No indexed pair	`200 OK`, `pairCount: 0`, `sourceStatus: no_indexed_pairs`
Cache behavior	Short upstream cache may apply; do not assume tick-by-tick pricing

JavaScript example

async function getTokenSnapshot(baseUrl, apiKey, address) { const url = `${baseUrl.replace(/\/$/, "")}/v1/token/${encodeURIComponent(address)}`; const response = await fetch(url, { headers: { Accept: "application/json", Authorization: `Bearer ${apiKey}` } }); const body = await response.json(); if (!response.ok) { throw new Error(body?.error?.message || `Request failed: ${response.status}`); } return body.data; } const snapshot = await getTokenSnapshot( "https://YOUR-INOKOMD-WORKER.workers.dev", "YOUR_API_KEY", "0x6982508145454Ce325dDbE47a25d4ec3d2311933" ); console.log(snapshot.pairs[0]?.priceUsd ?? "Price unavailable");

04 · Data model

Normalized response fields

Field	Type	Meaning
`data.query.address`	string	Address requested
`data.pairCount`	number	Number of returned pairs
`pairs[].chain`	string \| null	Chain identifier reported for the pair
`pairs[].token`	object	Base token address, name, and symbol
`pairs[].priceUsd`	number \| null	Reported token price in USD
`pairs[].priceChangePct`	object	Price change percentages for m5, h1, h6 and h24
`pairs[].liquidityUsd`	number \| null	Reported liquidity in USD
`pairs[].volumeUsd`	object	Trading volume by time window
`pairs[].transactions.h24`	object	Reported buy and sell transaction counts
`pairs[].marketCap`, `fdv`	number \| null	Valuation metrics when provided by the source
`meta.requestId`	string	Identifier useful for support and debugging
`meta.generatedAt`	string	Time the API response was generated

05 · Error handling

HTTP status and error codes

Status	Code	Meaning / action
400	`INVALID_ADDRESS`	Check the address format and network.
401	`UNAUTHORIZED`	Missing or invalid API key; check the Bearer header.
404	`NOT_FOUND`	Route does not exist; verify the base URL and path.
405	`METHOD_NOT_ALLOWED`	This API route accepts GET requests.
502	`UPSTREAM_UNAVAILABLE`	Retry with backoff; upstream market data may be temporarily unavailable.
503	`SERVICE_NOT_CONFIGURED`	Operator must configure API keys on the Worker.

Error response format

{ "error": { "code": "UNAUTHORIZED", "message": "A valid InokoMD API key is required in the Authorization header.", "requestId": "server-generated-id" } }

06 · Authentication

API key handling

Send keys in the Authorization header using the Bearer scheme.
Do not put API keys in query strings, public repositories, screenshots, or client-side source code.
Use separate keys for development and production; rotate a key immediately if it is exposed.
Never send payment card details to the InokoMD API.

GET/v1/keys/self

Returns whether the supplied key is accepted by the configured Worker. The included starter implementation returns a configured plan label; connect this route to your customer database before exposing real subscription and usage details.

07 · Usage policy

Plans, quotas, and retries

Commercial plans should define monthly request quotas, rate limits, allowed use, support level, and overage behavior. The included Worker starter validates configured keys but does not yet enforce per-customer monthly quotas or persist usage events.

Recommendation	Implementation
Rate limiting	Apply per-key limits using a durable store or Cloudflare rate-limiting controls.
Usage metering	Record request counts and timestamps without logging raw keys.
Retries	Retry 502/503 with exponential backoff; avoid tight loops.
Timeouts	Set client-side timeouts and show a clear retry state.
Data freshness	Show response time and avoid treating cached values as real-time guarantees.

09 · Integration patterns

Build a reliable token data pipeline

For production integrations, treat each snapshot as a time-stamped observation rather than a permanent token fact. Store the contract address, returned pair identifiers, response timestamp, and source status together so downstream systems can distinguish missing data from a zero value.

1. Validate input

Normalize whitespace, validate the address format expected by the target chain, and reject empty values before issuing a request. The endpoint accepts a token address, not a symbol or project name.

2. Authenticate server-side

Send the key in the Authorization: Bearer header from your backend. Do not ship a paid production key in a browser bundle or mobile app.

3. Interpret the result

Check the HTTP status, meta.sourceStatus, and data.pairCount. A valid request with no indexed pairs is not the same as a failed request.

4. Cache and refresh

Use a short cache for rapidly changing market data, record when each snapshot was fetched, and avoid polling more frequently than your plan allows.

10 · Verified address examples

Use real contract addresses

These are widely used Ethereum mainnet token contract addresses. They are examples for testing address lookup; the endpoint may return multiple trading pairs or no indexed pair depending on market-data coverage.

Token	Network	Contract address
PEPE	Ethereum	`0x6982508145454Ce325dDbE47a25d4ec3d2311933`
SHIB	Ethereum	`0x95aD61b0a150d79219dCF64E1E6Cc01f0B64C4cE`
WETH	Ethereum	`0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2`
USDC	Ethereum	`0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`

Select Use address to copy a sample into the API console. This does not send a request; press Run request after adding your Worker URL and API key.

11 · Production response handling

Robust client implementation

Handle transport errors separately from API errors, and preserve the request ID when raising an incident. Use explicit timeouts and do not treat unavailable metrics as zero.

async function fetchInokoMDToken({ baseUrl, apiKey, address }) { const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 10000); try { const response = await fetch( `${baseUrl.replace(/\/$/, "")}/v1/token/${encodeURIComponent(address)}`, { method: "GET", headers: { Accept: "application/json", Authorization: `Bearer ${apiKey}` }, signal: controller.signal } ); const payload = await response.json().catch(() => null); if (!response.ok) { const code = payload?.error?.code ?? "HTTP_ERROR"; const requestId = payload?.error?.requestId ?? "unavailable"; throw new Error(`${code}; HTTP ${response.status}; request ${requestId}`); } if (!payload?.data || !Array.isArray(payload.data.pairs)) { throw new Error("INVALID_RESPONSE_SCHEMA"); } return { requestId: payload.meta?.requestId ?? null, sourceStatus: payload.meta?.sourceStatus ?? "unknown", pairs: payload.data.pairs }; } finally { clearTimeout(timeout); } } // Example: use PEPE on Ethereum const result = await fetchInokoMDToken({ baseUrl: "https://YOUR-INOKOMD-WORKER.workers.dev", apiKey: "YOUR_API_KEY", address: "0x6982508145454Ce325dDbE47a25d4ec3d2311933" }); console.log(result.sourceStatus, result.pairs);

08 · Operator setup

Deploy the InokoMD API Worker

Deploy worker.js as a Cloudflare Worker (separately from the static website).
In Worker settings, add INOKOMD_API_KEYS as a secret or protected variable containing issued test keys separated by commas.
Optionally set ALLOWED_ORIGIN to your official InokoMD website origin.
Open /v1/health to confirm the Worker responds, then call /v1/token/{address} with a configured key.
Before selling access at scale, replace the starter comma-separated key list with a proper key database, hashed key storage, revocation, per-plan quotas, usage metering, billing events, and monitoring.

The included Worker is a functional starter API, not a fully managed billing platform. Its market snapshot is normalized behind the InokoMD API contract, while the Worker retrieves market information from an upstream public data service. Do not advertise paid access as live until this Worker is deployed, tested, and connected to your real customer and billing systems.

# Health check (no key required) curl "${API_BASE_URL}/v1/health" # Authenticated token snapshot curl "${API_BASE_URL}/v1/token/YOUR_TOKEN_ADDRESS" \ -H "Authorization: Bearer ${INOKOMD_API_KEY}" \ -H "Accept: application/json"