API Glossary for Analysts: The Terms You Hear in Every Integration Meeting
Written by Ahmed at Analyst Engineering, a Senior Technical Business Analyst with 10+ years in banking and payments delivery.
Key takeaways
- An endpoint is one URL and method combination an API exposes, such as POST /v1/payments; an API is the whole set of endpoints and the rules that govern them.
- A payload is the data carried in the body of a request or response, usually JSON; headers are the metadata that travel alongside it, such as the credential and the content type.
- Authentication proves who is calling and fails with 401; authorization decides what that caller may do and fails with 403.
- A webhook reverses the direction of an API call: instead of your system asking for updates, the provider sends an HTTP request to your URL when something happens.
- An idempotency key is a unique value a client sends with a request so that retrying the same request does not perform the operation twice, which is how payment APIs prevent duplicate charges.
This glossary defines the API terms analysts hear in refinement, integration workshops, and incident calls, in plain language with a real example for each. It is written for analysts who are new to APIs but not new to delivery: the words are technical, the explanations are not.
API terms to know first: an API is the interface a system exposes; an endpoint is one operation in it, such as POST /v1/payments; a request carries a method, URL, headers, and a payload; a response returns a status code, headers, and a payload. Around those sit the words for security (authentication, token, scope), for behavior (idempotency, pagination, rate limit, webhook), and for tooling (collection, environment, mock). Every term below has a one-line meaning and an example of where you will meet it.
APIs for Analysts, beginner track. Read this alongside Part 1, what is an API. Full learning path: APIs for Analysts.
Keep this page open during your next integration meeting. When a developer says “the webhook is idempotent on the event ID but the list endpoint is cursor-paginated”, every word of that sentence is defined below. If you want the broader technical vocabulary beyond APIs, The Technical Skills Guide for BAs covers SQL, logs, and code reading in the same style.
What are the basic API terms?
| Term | Plain meaning | Where you meet it |
|---|---|---|
| API | Application Programming Interface: the published way one program asks another for data or an action | ”The core banking API exposes accounts and payments.” |
| Client | The program sending the request | Your mobile app, Bruno, Postman, a batch job |
| Server | The program receiving the request and responding | The payments service |
| Endpoint | One operation: a method plus a path | GET /v1/payments/{id} |
| Resource | The business thing an endpoint acts on | A payment, a customer, an account |
| Base URL | The fixed start of every endpoint’s address, per environment | https://api.github.com, https://sit.payments.internal |
| Path | The part of the URL after the host that identifies the resource | /repos/usebruno/bruno |
| Path parameter | A variable segment of the path identifying one resource | {id} in /payments/{id} |
| Query parameter | A key and value after ? that filters, sorts, or pages | ?state=open&per_page=5 |
| Method (verb) | The kind of operation | GET read, POST create, PUT replace, PATCH update, DELETE remove |
| Request | Everything the client sends: method, URL, headers, body | A payment submission |
| Response | Everything the server returns: status, headers, body | The created payment |
| Header | A named piece of metadata on a request or response | Content-Type: application/json |
| Body / payload | The data carried in a request or response | The JSON with amount and IBANs |
| Status code | A three-digit outcome of the request | 200 OK, 404 Not Found, 500 server error |
| JSON | The text format most APIs use for payloads | { "amount": "125.00" } |
| Schema | The rules a payload must follow: fields, types, lengths, required | ”creditor.name is a string, max 70 characters” |
The two families that deserve their own reading are status codes, in HTTP status codes explained, and JSON structure, in JSON for analysts.
What do the security and access terms mean?
| Term | Plain meaning | Where you meet it |
|---|---|---|
| Authentication | Proving who is calling. Fails with 401 | Sending a valid token |
| Authorization | Deciding what the caller may do. Fails with 403 | A read-only token trying to create a payment |
| API key | A long secret string identifying a calling application | x-api-key: ... header |
| Bearer token | A token sent as Authorization: Bearer <token>; whoever bears it gets access | Most OAuth-protected APIs |
| OAuth 2.0 | The standard framework for issuing access tokens | ”Get a token from the identity provider first.” |
| Client credentials flow | The OAuth flow where a system exchanges a client ID and secret for a token | Server-to-server bank integrations |
| Access token | A short-lived credential, often valid for an hour | expires_in: 3600 |
| Refresh token | A longer-lived credential used to get new access tokens | User-facing apps |
| Scope | The permissions a token carries | payments:read, payments:write |
| PAT | Personal access token: a token tied to a person’s account | GitHub or Jira tokens for scripts |
| mTLS | Mutual TLS: both sides present certificates | Bank-to-scheme connections |
| Secret | Any credential that must never be committed or shared | Client secrets, keys, passwords |
How each credential type should be scoped, stored, and rotated is in API keys, PATs, and OAuth tokens.
What do the contract and environment terms mean?
| Term | Plain meaning | Where you meet it |
|---|---|---|
| Contract / specification | The precise, agreed definition of the interface | ”Is that field in the contract?” |
| OpenAPI | The standard format for describing REST APIs in YAML or JSON | openapi.yaml in the repository |
| Swagger | The older name of OpenAPI, and a family of tools such as Swagger UI | ”Check the Swagger page.” |
| AsyncAPI | The equivalent of OpenAPI for event-driven interfaces | Kafka topic definitions |
| Documentation | The human guide around the contract: getting started, flows, errors | A developer portal |
| SDK | Software development kit: a code library that wraps an API | Stripe’s libraries for various languages |
| Environment | A separate deployment of the system | DEV, SIT, UAT, PROD |
| Sandbox | A provider’s safe test environment where no real money or data moves | Stripe sandbox, a bank’s developer sandbox |
| Mock | A fake API that returns predefined responses | A Prism mock generated from OpenAPI |
| Version | A labelled state of the contract consumers can rely on | /v1/, Stripe-Version, X-GitHub-Api-Version |
| Breaking change | A change that makes existing consumers fail | Removing a response field |
| Deprecation | An announcement that something will be removed later | A Deprecation response header |
Reading the contract yourself is covered in reading an API contract, and what makes a change breaking in API versioning and breaking changes.
What do the API behavior terms mean?
| Term | Plain meaning | Where you meet it |
|---|---|---|
| Synchronous | The caller waits for the final answer in the response | A balance enquiry |
| Asynchronous | The response only acknowledges; the outcome arrives later | A payment returning 202 Accepted |
| Polling | Repeatedly asking for a status until it changes | GET /payments/{id} every few seconds |
| Webhook | The provider calls your URL when an event happens | Stripe sending payment_intent.succeeded |
| Callback | A general term for a later call back to the requester; often a webhook | ”The scheme sends a callback on settlement.” |
| Event | A record that something happened, published for others to react to | payment.settled on a Kafka topic |
| Idempotent | Doing it twice has the same effect as doing it once | PUT, DELETE, a replayed request with the same key |
| Idempotency key | A unique value sent so a retry is recognized and not reprocessed | Idempotency-Key header on Stripe POST requests |
| Retry | Sending a failed request again, ideally with backoff | After a timeout or 503 |
| Backoff | Waiting longer between each retry | 1s, 2s, 4s, 8s |
| Timeout | The maximum time a client waits before giving up | ”Our gateway times out at 30 seconds.” |
| Rate limit | A cap on requests per time window; exceeding it returns 429 | GitHub’s X-RateLimit-Remaining |
| Throttling | Slowing or rejecting requests to protect a service | Usually used interchangeably with rate limiting |
| Pagination | Splitting a large list into pages | ?page=2, or a cursor |
| Cursor | An opaque pointer to where the next page starts | Stripe’s starting_after, GraphQL’s endCursor |
| Filtering | Narrowing a list with parameters | ?status=failed&created_after=2026-09-01 |
| Latency | How long a request takes | ”p95 latency is 400 ms.” |
| API gateway | The front door that checks credentials, limits, and routes requests | Where many 401 and 429 responses come from |
| Trace ID / request ID | A unique ID for one request, used to find it in logs | Stripe’s Request-Id header |
The asynchronous terms are the ones analysts most often underestimate, because they change requirements, testing, and investigation. Synchronous vs asynchronous and webhooks explained for analysts go deeper, and idempotency testing shows how to prove duplicates are safe.
What do the tooling terms mean?
| Term | Plain meaning | Where you meet it |
|---|---|---|
| curl | A command line tool that sends HTTP requests | curl -i https://api.github.com |
| API client | A desktop tool for building and saving requests | Bruno, Postman |
| Collection | A saved, organized set of requests | ”Run the payments collection against SIT.” |
| Environment variables | Named values that change per environment | {{baseUrl}} |
| Pre-request script | Code that runs before a request is sent | Generating a unique reference |
| Post-response script | Code that runs after the response arrives | Capturing the payment ID |
| Assertion / test | A check that passes or fails on the response | ”Status equals 201” |
| Chaining | Passing values from one response into the next request | Create payment, then poll its status |
| Collection runner | Runs a collection’s requests in order | Bruno Runner, Postman Collection Runner |
| CLI runner | Runs a collection from the command line, for pipelines | bru run, newman run |
| CI | Continuous integration: automated checks on every change | API tests gating a merge |
| Copy as cURL | A browser DevTools option that copies a request as a curl command | Replaying what a screen sent |
Setting all of these up is Part 2, your first API collection, and running them in a pipeline is API tests in CI.
What do the API style terms mean?
| Term | Plain meaning | Where you meet it |
|---|---|---|
| REST | An API style built on resources, URLs, and HTTP methods | Most public and internal JSON APIs |
| GraphQL | An API style with one endpoint where the client asks for exactly the fields it wants | The GitHub GraphQL API |
| SOAP | An older XML-based API style described by a WSDL file | Core banking and insurance systems |
| WSDL | The contract file for a SOAP service | AccountService.wsdl |
| gRPC | A fast binary API style used between internal services | Service-to-service calls |
| Message queue / topic | A channel where systems publish and consume messages | Kafka, RabbitMQ, AWS SQS |
GraphQL behaves differently enough to need its own guide: GraphQL for analysts.
Which API terms get confused most often?
These pairs cause more misunderstanding in meetings than any single term.
| Confused pair | The difference |
|---|---|
| API vs endpoint | The whole interface vs one operation in it |
| Authentication vs authorization | Who you are (401) vs what you may do (403) |
| PUT vs PATCH | Replace the whole resource vs change part of it |
| 200 vs 201 vs 202 | Done vs created vs accepted for later processing |
| 400 vs 422 | Structurally invalid vs valid structure breaking a business rule (by common convention) |
| Webhook vs polling | The provider tells you vs you keep asking |
| Contract vs documentation | The precise interface vs the human guide to using it |
| Sandbox vs mock | The provider’s real system in test mode vs a fake that returns examples |
| Timeout vs failure | ”I stopped waiting” vs “it told me no”. After a timeout the operation may still have succeeded |
| API key vs token | Usually long-lived and per application vs usually short-lived and scoped |
The timeout row is the one with the biggest consequences in payments. A timeout tells you nothing about whether the money moved, which is precisely why idempotency keys exist.
The APIs for Analysts learning path
Beginner: What is an API · API glossary (you are here) · JSON for analysts · HTTP status codes · Your first collection · Why did my API request fail? · Reading an API contract
Intermediate: Analyze an API · Document an API · API test cases · Chaining and scripts · Webhooks · GraphQL
Advanced: POCs and demos · API design review · Versioning and breaking changes · API security testing · API tests in CI
The takeaway
API conversations use a compact vocabulary: the parts of a request and response, the words for access, the words for contracts and environments, and the words for behavior over time. The terms that matter most for analysts are the ones that change requirements: asynchronous, webhook, idempotency key, rate limit, pagination, and breaking change. Learn those, keep the confused pairs straight, and you can follow, and challenge, any integration discussion.
Grab the free downloads for more quick references, go deeper with The Technical Skills Guide for BAs, or book a 1:1 Tech BA Coaching Call if you are new to APIs and want a guided start on your own project.
Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.
Tags: API, Glossary, Business Analysis, Beginners, Integration
About the author
Analyst Engineering is written by Ahmed, a Senior Technical Business Analyst with 10+ years of banking and payments delivery experience: ISO 20022 and SWIFT messaging, payments API integration, Kafka event validation, and production support. Every article comes from real delivery work, and each one is reviewed and updated as tools and standards change.
Related articles
- What Is an API? How APIs Actually Work, Explained for Analysts What an API is and how one works, for analysts: request and response, methods, headers, auth, status codes, and a real GitHub API call you can send today.
- Why Did My API Request Fail? Troubleshooting Your First API Calls Troubleshoot failed API requests by symptom: connection and SSL errors, 401 vs 403, wrong-URL 404s, 415 and 422, 429, 5xx, CORS, and unresolved variables.
- JSON for Analysts: Read the Payload Fluently How an analyst reads JSON: objects, arrays, nesting, and types. Understand API payloads, event messages, and config without asking a developer. Practical, not theory.
- HTTP Status Codes Explained: What 200, 202, and 409 Really Mean An analyst's guide to HTTP status codes: the 2xx, 4xx, and 5xx families, what each common code means, and why 202 vs 200 matters in payments. Practical, not exhaustive.
Free account
Practice on the Labs, keep your progress
A free account, no password: an email link signs you in. It saves your steps and self-assessments on the Labs, shows your missions on a dashboard, unlocks the solutions, and, if you tick the box, sends you new missions and articles when they ship.
Your email is used to sign you in. Nothing else, unless you ask. Privacy.