Built on CardAPI: Churn
Churn helps people get more from their credit cards: which card to use, which credits are still unused, which issuer rules they're up against, where their points transfer. Its card data comes from CardAPI. Churn and CardAPI are made by the same team, so read this as how we use our own API, not as a customer testimonial.
Plan
Enterprise planChurn runs on the Enterprise plan, from one server-side key. The key is never sent to the browser: anything that needs it goes through Churn's own server routes, which call CardAPI. The only call made from the browser is the public GET /v1/stats, which takes no key.
The endpoints Churn calls
As of 2026-10-15, Churn's CardAPI client wraps these 13 endpoints:
- GET /v1/cardsthe full catalogue, page by page (also read by its fee and bonus reminder jobs)Every plan
- GET /v1/cards/:slugone card's detailsEvery plan
- GET /v1/cards/searchcard searchEvery plan
- GET /v1/cards/bestthe best cards for a spending categoryEvery plan
- GET /v1/cards/:slug/historya card's change historyPro plan and above
- GET /v1/cards/:slug/transferswhere a card's points transferPro plan and above
- GET /v1/cards/:slug/perkscompanion perksStarter plan and above
- GET /v1/cards/:slug/creditsa card's statement creditsStarter plan and above
- GET /v1/transfer-partnersthe transfer partner directory, for its transfers pagePro plan and above
- GET /v1/application-rulesits issuer rules page (Chase 5/24 and the rest)Every plan
- GET /v1/offers/historya card's welcome-offer historyPro plan and above
- GET /v1/reward-valuationsits points valuations pageEvery plan
- GET /v1/product-changesits product-change paths pageEvery plan
It also reads these 2 outside that client:
- GET /v1/offers/notableits deal alerts, through its own server routePro plan and above
- GET /v1/statsthe stats bar on its landing page, read from the browser (public, no key)Every plan
It doesn't use webhooks or GraphQL today; it re-reads on a schedule instead.
How it calls them
- Most responses are cached for up to an hour with Next.js incremental static regeneration, and offer alerts for 5 minutes, so visitors never wait on the API.
- The server client retries 429 and 5xx answers with backoff (1 s, then 2 s); a 404 is an expected answer for an unknown card.
- In the server client, a failed call throws instead of returning an empty list, so a regenerated page never caches "no cards" during an outage; the last good page stays up. (Its browser proxies answer with empty data and an error code instead.)
- The server client is server-only: importing it from browser code fails the build, which keeps the key off the client.
Build something like it
The same approach, step by step: a comparison site with Next.js. For a wallet-based "which card" feature, see the rewards optimizer use case, and for transfers and credits, the travel app. Plans and what each returns: pricing.