Find crypto cards for a US user that accept USDC funding, then rank them for stablecoin spending.
Reviewed crypto card data for software and people
API / Agents
cryptocard.guide turns reviewed provider evidence into comparable card profiles and explainable rankings. The same research is available through normal web pages, JSON, Markdown and public recommendation endpoints, so an AI agent can find a suitable card, explain the result and cite the evidence behind it.
Reviewed facts, ready for questions
A visitor can browse the catalogue and compare cards visually. An agent can ask the same research layer a structured question without scraping tables or guessing what a field means.
The API treats US as country context, applies the funding and asset requirements, ranks the remaining cards with the requested scenario and returns reasons, unknowns, sources and any relevant current offer.
What you can use
- Published card profiles with review dates, source coverage, scores, caveats and structured funding routes.
- Deterministic recommendations for country, funding method, asset and use-case scenario.
- Reviewed offers with audience, status, user benefit, requirements, expiry and conservative value normalization.
- Canonical web pages and selected evidence links for citation.
- Stable application links with the current provider destination and clear partner disclosure.
How agents find the API
The root /llms.txt file points to this guide, the card index, recommendation endpoint, offers endpoint and OpenAPI document. An agent that starts on a card or catalogue page can follow the same links from there.
These endpoints are read-only and do not require an account or API key. Responses include links back to the equivalent browser result and the canonical pages suitable for citation.
Card data formats
/api/v1/cards returns the published card index. /api/v1/cards/{slug} returns one reviewed public profile as JSON. Send Accept: text/markdown to either card endpoint for a compact Markdown representation.
Card records include the canonical page, last-checked date, source confidence, selected evidence, explicit unknowns, score explanation, structured funding routes and the current application link. Machine representations are marked noindex. The normal HTML page remains the canonical citation and search URL.
Use a web link or the matching API
The web pages and APIs use the same public parameters. A user can open the result in a browser, while an agent can request the JSON form of the same question.
Find cards
Find current offers
The recommendation API also supports an additional agent-focused ranking lens: /api/v1/recommendations?country=US&funding=crypto&asset=USDC&scenario=stablecoin_spend. The stablecoin_spend scenario is not shown as a main catalogue tab.
Recommendation parameters
countryUS,CA,GB,DEand other country codes available in the site selector.EU,EEAandALLare also accepted.fundingany,crypto,bank,cardorinternal. Crypto includes reviewed on-chain funding from an external wallet. Internal means a transfer within the provider's own account or card system. The API does not connect to or inspect a wallet.asset- One asset code, for example
USDT, or a comma-separated list, for exampleUSDC,USDT. scenariooverall,cashback,travel,funds_control,low_fees,stablecoin_spendortransfers.limit- From 1 to 50 results.
Funding and asset requirements are strict. Unknown support does not pass them. Country is soft context: a card is excluded only by explicit unavailability or a complete allowlist that omits the selected country.
Why a card fits, then what the user can get
Each result first explains the product fit: score reasons, country context, funding routes and unresolved unknowns. It then adds the current application link and any relevant offer. This gives an agent enough information to explain the card before mentioning a promotion. In JSON, these groups are named fit and commercial.
Offers do not change card scores, ranking order or recommendation eligibility.
Offer value and country context
Each offer describes what an eligible user may receive, the requirements, deadline and whether its value can be compared with another offer. A return-at-requirement percentage is calculated only when a fixed benefit and minimum spend use the same asset. Up-to rewards, multipliers and unlike currencies remain explicitly non-comparable.
Card availability and offer eligibility are reported separately. If offer terms do not confirm the selected country, the response says so instead of assuming eligibility.
Citation guidance
API responses provide the useful machine-readable context, while the linked canonical page gives a stable public citation target.
- Cite the canonical card or offer page linked in the response.
- Retain the published last-checked date and relevant conditions.
- Preserve unknowns, exclusions and regional caveats.
- Use the linked official evidence when the provider claim is the better primary citation.
What makes an answer trustworthy
- Public claims come from published, human-reviewed profiles.
- Unknown data remains unknown and does not count as positive evidence.
- Each result keeps its last-checked date, conditions and relevant source links close to the claim.
- Offers are added only after the recommendation order is fixed.
- Read-only access supports JSON, Markdown and cross-origin requests without an API key.
- Canonical HTML is server-rendered and discoverable through ordinary navigation, robots rules and the sitemap.
MCP compatibility
MCP is not required to use the data today. If agent clients need tool-style access later, a future MCP server can wrap the same card search, recommendations, offers and source lookup. It would use the same reviewed facts and ranking logic as the web and API.