Back to blog
best-practicestutorial

Best Practices for Using the Blotd API

CurtisFebruary 18, 20265 min read

Get the most out of your API calls

Blotd gives you a generous request allowance on every plan, but smart usage patterns will keep your app fast and your quota healthy. Here are the practices we recommend to every developer integrating Blotd.

Cache aggressively on the server

Blog content changes infrequently. There is no reason to hit the API on every single page view. If you are using Next.js, add a revalidate interval to your fetch calls:

await fetch(url, { next: { revalidate: 60 } })

This tells Next.js to serve a cached response for 60 seconds before revalidating in the background. One API call serves thousands of visitors. Astro, Nuxt, and SvelteKit all have similar ISR or caching mechanisms. Use them.

Even better: use on-demand revalidation

Time-based caching is good, but on-demand revalidation is better. Instead of refreshing your cache every 60 seconds whether content changed or not, you can tag your fetch calls and only invalidate the cache when you actually publish, update, or delete an article.

In Next.js, use the tags option on your fetch:

await fetch(url, { next: { tags: ["blog"] } })

Then in whatever webhook or internal route handles content changes, call revalidateTag("blog"). Your pages stay fully cached until content actually changes, meaning zero wasted API calls and instant updates when you hit publish. This is the approach we use on our own blog page.

Use static generation where possible

If your blog does not change every minute, consider building it statically. Fetch all articles at build time, generate the HTML pages, and deploy them to a CDN. Zero API calls at runtime, instant page loads, and your monthly quota stays untouched between deploys.

Protect your API key

Your Blotd API key should never appear in client-side JavaScript, public repositories, or browser network requests. Store it as an environment variable and only reference it in server-side code. In Next.js that means server components, route handlers, or getServerSideProps. In Astro, use it inside the frontmatter fence. If you suspect a key has been exposed, revoke it from your dashboard immediately and generate a new one.

Fetch only what you need

Use the pagination parameters to limit response sizes. If your homepage shows the latest 5 posts, request ?limit=5 instead of the default 10. If you need articles for a specific section, filter by tag with ?tag=tutorials. Smaller responses mean faster load times and less bandwidth.

Handle errors gracefully

Network requests fail. The Blotd API returns clear HTTP status codes: 401 for bad keys, 404 for missing articles, 429 when you hit your rate limit. Build fallback UI for each case. Show a cached version when the API is unreachable. Display a friendly message when an article is not found. Never let an API error crash your page.

Monitor your usage

Your Blotd dashboard shows real-time API usage, including daily and monthly call counts per key. Check it regularly. If you are approaching your limit, that is a signal to add caching, switch to static generation, or upgrade your plan. Staying ahead of your quota means your readers never see a failed request.