You know what an API is, and you have a token and a documentation page. Now you need one call that works, and a clear next step when it does not. If you want the theory first, start with REST APIs for Analysts. This article only covers the call itself.
Every example uses a hypothetical endpoint, api.example.com, with invented fields and responses. The commands and code have not been run against a real API. Your API's documentation decides the real URL, parameters and field names.
Keep the token out of your code and notes
Here is the request you are about to send, written out with a placeholder:
GET /v1/reports?date=2026-10-01 HTTP/1.1
Host: api.example.com
Authorization: Bearer YOUR_API_TOKEN
Accept: application/jsonThe Authorization line is where many APIs expect the token, although some use another header. Check the docs. The bearer format comes from RFC 6750, which also explains the risk: any party in possession of a bearer token can use it. No further proof is needed.
So never paste a real token into a script, a notebook, a ticket, a chat message or shared notes. Put it in an environment variable instead. In Bash, this prompts for the value without showing it or saving it in your shell history:
read -rs API_TOKEN
export API_TOKENIf a real token does end up somewhere shared, deleting the line is not enough, because copies may remain in Git history or message logs. Revoke it and create a new one. OWASP's secrets management guidance adds that secrets should never be logged, and that those found in code or logs must be removed immediately.
