The ones this skill picks don't. Free tier only, with the tier's real limits stated before you sign up.

Skills / Use an API

Use an API

Q: What if I leak a key anyway?

Revoke it in the provider's dashboard and issue a new one. The workflow prevents it: ignore rule before the key exists, then git status and git log -p to prove history is clean.

Q: Do I need a backend for this?

Not to start. A key shipped in frontend code is visible in dev tools though; when it must be truly hidden, backend-basics is the next step.

Q: What is a rate limit and will I hit it?

The number of requests the API allows per minute or day. You find yours in the docs and design around it by caching or fetching on demand.

Q: Which API should I pick?

One that feeds something you care about: weather, transit, game or music data, or a public dataset from your country. Keyless APIs are a good first run.

Call a real public API from their project. Read the docs together, auth with a key kept out of git, handle errors and rate limits, and ship a feature powered by live data. Use when they want weather, scores, prices, or any outside data in an app, or ask "how do APIs work".

Use this skill. Nothing to install.

Open in ChatGPT Open in Claude prefilled and ready; just hit send

for Gemini, Copilot, or Cursor: paste it, then say "use the use an api skill"

Don't have an agent? · Raw file: skills/use-an-api.md

Watch the first two minutes

This is how a session goes, including the part everyone is afraid of. Click through it.

(pastes the skill) can my site show the actual weather for my city?

Yes, with a weather API. First: which city, and is the site already in a repo I can build on?

austin, and yeah it's on github pages. but i keep reading about people leaking API keys and getting huge bills

Real worry, and the skill is built around it. Two habits: the ignore rule goes into git before the key even exists, and we start on an API that needs no key at all. Plenty of good weather APIs are free and keyless, so your first request risks nothing.

how would a key even leak?

You commit it once and push. Then it lives in your git history even if you delete the line later. So: ignore rule first, key second, and we check both git status and git log -p to prove it never landed.

ok. where do we start

Docs before code. Find four facts on the API's docs page: base URL, one endpoint, the auth method, the rate limit. Then we hit the endpoint with curl and read the raw JSON together. Seeing it raw demystifies the whole thing.

Scripted example of a real session.

Won't I leak my key and get a giant bill?

This is the fear the skill takes most seriously. It only uses free tiers, and it says out loud what each free tier allows before you sign up. The key goes in an environment variable or an untracked config file from the first minute, with the ignore rule added before the key exists. Then you prove it: git status shows nothing secret staged, and a spot-check of git log -p shows nothing secret in history. These projects all run on APIs handled exactly that way:

Price-drop watcher on a schedule

One email instead of three apps

Discord bot your server uses

What you end up with

A live feature on your own page, fed by real outside data, plus the four facts that make the next API easier than this one. Here is the shape of the finished thing.

Example

FIRST CONTACT, BEFORE ANY CODE

$ curl "https://api.example.com/v1/forecast?city=austin"
{
  "city": "Austin",
  "temp_f": 74,
  "condition": "clear",
  "updated": "2026-07-20T14:00:00Z"
}

THE FOUR FACTS, WRITTEN AS A COMMENT

// base URL:   https://api.example.com
// endpoint:   /v1/forecast?city=...
// auth:       key in X-Api-Key header (free tier)
// rate limit: 1000 requests/day, cache accordingly

WHERE THE KEY LIVES

$ cat .gitignore
config.js
$ git status
nothing secret staged

The feature uses two fields. The response has a dozen; the page renders temp_f and condition. Picking the few fields you need from real JSON is most of the work.
The comment is the durable part. Every API you ever use reduces to these four facts. Finding them in the docs yourself is the skill; this API is just the first one.
The proof is a command, and you run it. Nothing secret in git status, nothing secret in history.

Anatomy of an API request

Every request you'll ever make breaks into the same parts:

https://api.example.com/v1/forecast?city=austin · X-Api-Key: $WEATHER_KEY

A Base URL: which service you're talking to.
B Endpoint: which question you're asking it.
C Params: the specifics of your question.
D The key, read from an env var, never written into the URL or the code.

Questions people actually ask

Do APIs cost money?

The ones this skill picks don't. Free tier only, and the skill states what the free tier actually allows (requests per day, attribution rules) before you sign up, so the limit is never a surprise.

What if I leak a key anyway?

You revoke it in the provider's dashboard and issue a new one; free-tier keys make this cheap to survive. Then the workflow that prevented it runs for real: ignore rule before key, and a git log -p spot-check to confirm history is clean.

Do I need a backend for this?

Not to start. But a key shipped in frontend code is visible to anyone who opens dev tools, and the skill says that plainly. When the key must be truly hidden, the next step is backend basics, where your own small server holds it.

What is a rate limit and will I hit it?

The number of requests the API allows you per minute or per day. You'll find yours in the docs and design around it: cache the response, or fetch on a button press instead of on every keystroke. Hitting it politely is part of the skill.

Which API should I pick?

One that feeds something you care about: weather for your city, transit near you, game or music data, a public dataset from your country. If it needs no key, even better for a first run; the skill has you meet both keyless and keyed APIs.

Where to go from here

Put the API to work in a project that earns a resume line:

Price-drop watcher on a schedule

Beat the forecast

Deadline aggregator

Ready for the next layer? These chain directly:

Backend basics: truly hide the key

Automate a task on a schedule

Database basics: keep the data

Ideas to use it on

An alumni and mentors directory that opts in — A directory connecting students at your school with alumni and adult mentors who explicitly opted in: where they work or study, what they'll take questions about, and how they prefer to be reached.
Beat the forecast — For one month, predict tomorrow's high temperature for your exact location and score yourself against the official forecast.
The chore rotation bot — Whose week is it for dishes, trash, or driving is a recurring argument in your house because the rotation lives in everyone's memory.
A deadline aggregator with its own backend — One page showing every deadline that matters to you and your classmates, pulled from the scattered places they actually live: a teacher's posted calendar (ICS feed), a class platform with an API or export, plus manual entry for the ones that exist only on a whiteboard.
A bot your Discord server actually uses — Some job in your Discord server is still done by a human: giving newcomers the right role, reminding everyone about game night, keeping a leaderboard for the running joke.
One email instead of three apps — Every morning you open the same three things: the weather, your team's score, the bus alerts, a subreddit, a webcomic.
A newsletter platform with real subscribers — A publishing platform for a newsletter a real group already wants: your neighborhood association's monthly update, your club's weekly recap, the scout troop's announcements.
A price watcher for the thing you want — There is a thing you are saving for, and you check its price by hand every few days.
QR check-in for a real event — Registration and door check-in for an event you or your group is actually running: a club showcase, a tournament, a fundraiser evening.

Curious? Read the full skill — the exact instructions your agent gets

---
name: use-an-api
category: code
description: Call a real public API from their project. Read the docs together, auth with a key kept out of git, handle errors and rate limits, and ship a feature powered by live data. Use when they want weather, scores, prices, or any outside data in an app, or ask "how do APIs work".
---

# use-an-api

Help someone call a real public API for the first time and
ship a feature on top of it. The goal is a page or app of theirs that
shows live outside data, plus the habits that make API work safe:
reading docs, keeping keys secret, and handling the request that fails.

## Ground rules

- Pick an API that feeds something they care about: weather for their
  city, transit near them, game or music data, a public dataset from
  their country. Free tier only, and say out loud what the free tier
  actually allows (requests per day, attribution rules) before they
  sign up.
- Their account, their key. They register themselves; you never see or
  type their password. The key lives in an environment variable or an
  untracked config file from the first minute. Add the ignore rule
  before the key exists, then prove it with `git status`.
- If the API needs no key (many good ones don't), start there and add
  a keyed API second, so they meet both worlds.
- Docs before code. Have them find the endpoint, the required params,
  and the rate limit in the docs themselves, with you pointing at the
  right page. Reading API docs is the durable skill; this API is just
  the first one.
- First contact is curl or the browser, before any code. Seeing raw
  JSON demystifies the whole thing.

## The path

1. Choose the API and read its docs together: base URL, one endpoint,
   auth method, rate limit. Write these four facts in a comment.
2. Hit the endpoint with curl or the browser URL bar. Look at the
   real JSON and pick the two or three fields the feature needs.
3. Sign up and get the key if one is needed. A frontend may contain only a
   key the provider explicitly documents as safe to publish in browser code.
   Anything shipped to a browser is public even when its source file was
   gitignored. Put a secret key in a server-side environment variable and
   hand off to backend-basics before shipping. Confirm no secret appears in
   source, built assets, browser dev tools, or git history, then make the call.
4. Build the feature: render the picked fields into their existing
   project or a small new page. Loading state while the request runs.
5. Break it on purpose. Wrong URL, bad key, network off. Handle each
   with a visible message instead of a blank page or console error.
   Respect the rate limit: cache the response or fetch on a button
   press instead of on every keystroke.
6. Ship it and write three lines in the README: what API, what it
   returns, where the key goes for anyone cloning the repo.

## Done

- A live feature showing real data from an API they chose
- A secret key, if any, stays server-side and is absent from source, built
  assets, browser dev tools, and git history; publishable frontend keys are
  identified from the provider's documentation
- Errors show a human message; the app survives the API being down
- They can explain endpoint, key, and rate limit in their own words

Then: backend-basics if the key must be truly hidden, since anything
shipped in frontend code is visible to anyone who opens dev tools.
Say that plainly here so the limit of the static approach is known.