API Interview Questions Asked in a
Business Analyst Interview
Diwakar Singh
Question:
As a Business Analyst, how did you gather and reconcile API
requirements when multiple downstream systems had conflicting
needs from the same Data Service?
Answer:
In my recent Data Services project in the wealth management
domain, this was actually the core challenge.
We were building a central Data Services layer that exposed client,
account, holdings, and transaction data via REST APIs to multiple
consumers – the advisor desktop, the client portal, a reporting
platform, and a risk engine. All of them wanted data from the same
/clients, /accounts, and /holdings APIs, but their needs weren’t
identical.
I followed a few steps:
1. Start with use cases, not endpoints
Instead of jumping into ‘what should the API look like’, I first
ran separate workshops with each consumer team:
a. For the advisor desktop, the main use case was ‘advisor
pulls up a client and sees all accounts and recent trades
in one view’.
b. For the client portal, the focus was ‘client self-service
view with masked fields and fewer technical attributes’.
c. For reporting, they needed more granular data, including
historical flags and audit attributes.
I documented these as use cases and data needs, not as technical
APIs yet. That helped everyone see the business scenarios first.
2. Create a canonical data contract
Once I had everyone’s requirements, I proposed a canonical
response model for, say, /clients/{clientId}:
a. A rich internal model including fields like riskProfile,
kycStatus, pepFlag, segmentCode, etc.
b. Then I worked with architects to define response shaping
and field-level entitlements, so different consumers
could get filtered views of the same canonical model.
For example:
c. Advisor desktop could see riskProfile and kycStatus.
d. Client portal would not see pepFlag or internal segment
codes.
3. Resolve conflicts with principles, not politics
A typical conflict:
a. Reporting team wanted very wide payloads (lots of
attributes).
b. The mobile client portal team wanted lean, optimized
payloads.
Instead of arguing over one ‘right’ payload, I suggested:
c. A standard minimal response for most consumers.
d. Optional include parameters
like ?include=taxDetails,riskProfile for those that needed
more.
As a BA I documented these rules clearly in the API spec and played
back the trade-offs in a joint session: payload size vs. simplicity vs.
flexibility.
4. Document decisions and non-requirements
I maintained a decision log in Confluence:
a. Why some fields were excluded from the public APIs.
b. Why some use cases were pushed to future versions.
When a new stakeholder later asked, ‘Why isn’t X field in the client
API?’, I could point back to the decision, not rely on memory.
So my role was less about ‘designing the API’ and more about
facilitating alignment, making the data contract explicit, and
ensuring every consumer’s use cases were satisfied without turning
the API into an unmanageable monster.
Question:
Describe a situation where you had to handle API versioning and
backward compatibility. How did you approach it as a BA in your
Data Services project?
Answer:
“In the Data Services project, we faced a classic versioning
problem with our Accounts API.
Initially, we had a /accounts/{accountId} endpoint that returned
basic information like accountNumber, accountType, currency, and
status. Later, the risk engine and compliance teams wanted more
detailed attributes like suitabilityCategory, regulatoryRestrictions,
and taxResidency. Changing the existing response in a breaking way
would have impacted the live advisor desktop application.
Here’s how I approached it:
1. Identify what’s truly breaking
I sat with the developers and walked through the current
Swagger spec and consumer usage:
a. Adding new optional fields was fine.
b. Renaming or changing the type of existing fields was not.
c. Changing business logic behind some fields (e.g., how
status is derived) could be considered breaking if
downstream systems rely on the current definition.
As a BA, I made sure business stakeholders understood that
‘changing the meaning of a field’ is as big a change as changing its
name.
2. Separate enhancements vs. versioned changes
We realized we could:
a. Extend v1 with a few non-breaking fields that were safe.
b. Introduce a v2 of the Accounts API for more sensitive
changes.
So we ended up with:
c. /v1/accounts/{accountId} – stable for existing
consumers.
d. /v2/accounts/{accountId} – with additional regulatory and
suitability attributes, plus a refined status model.
3. Run an impact analysis across consumers
I did a consumer impact walkthrough:
a. Reviewed with the advisor desktop team whether and
when they’d move to v2.
b. Confirmed the reporting platform actually wanted the
extra v2 attributes.
c. Agreed on a deprecation timeline for v1 once major
consumers migrated.
I documented these timelines and assumptions in Confluence and
in the release notes.
4. Clarify semantic changes in plain English
One key thing I did as a BA was to describe semantic changes
in non-technical language:
“Previously, ‘status = ACTIVE’ only checked if the account was open
in the core system. In v2, ‘ACTIVE’ also excludes accounts under
regulatory hold.”
That description went into:
a. The API documentation.
b. The UAT test scenarios.
c. The communication to downstream teams.
So my contribution around versioning was to make the impact
visible, align stakeholders on which changes go into v1 vs v2, and
ensure nobody was surprised when the ‘same field’ behaved
differently across versions.
Question:
How did you define and validate error handling and edge cases for
APIs in your Data Services project?
Answer (sample):
“Honestly, this is where a lot of API designs fall apart in the real
world – not in the happy path, but in how errors are handled.
In the Data Services project, we had a /holdings API that powered
both the advisor desktop and a portfolio reporting engine. There
were several tricky edge cases:
• Client with no active accounts.
• Accounts with pending transfers.
• Security positions with stale or missing market prices.
Here’s what I did as a BA:
1. Map business scenarios to technical errors
Instead of starting with HTTP codes, I first listed business
scenarios:
a. Client exists but has no active holdings → should not be
treated as an error.
b. Client ID not found in the master system → business
error.
c. Downstream pricing service unavailable → technical
error.
Then I worked with the tech lead to map these to:
d. 200 OK with empty holdings array for ‘no holdings’.
e. 404 with a business error code like CLIENT_NOT_FOUND.
f. 503 with PRICING_SERVICE_UNAVAILABLE when market
data was down.
2. Define a standard error model
I pushed for a consistent error response structure across all
Data Services APIs:
{
"timestamp": "2025-12-28T10:45:00Z",
"traceId": "abc123",
"errorCode": "CLIENT_NOT_FOUND",
"message": "Client ID 12345 does not exist.",
"details": []
}
This made it easier for downstream teams to handle errors without
custom parsing for each API.
3. Use realistic examples in specs and UAT
In the API documentation and UAT test cases, I included real
examples from the wealth domain:
a. A closed account still appearing in the core system but
not eligible for trading.
b. Securities that had corporate actions applied, making
certain positions look odd.
For example, we wrote a test case:
c. “When a client’s last account is closed, calling /holdings
should return 200 with an empty array, and the UI should
show ‘No active holdings’ instead of a generic error.”
4. Test with non-happy data
I worked with QA to make sure we had test data that:
a. Simulated clients with pending KYC issues.
b. Included accounts across multiple book of records.
c. Contained stale or missing market price data.
During UAT, we actually found that one consumer treated 404 as
‘API not deployed’. That led to a discussion and we agreed to return
200 with an empty result for some scenarios to avoid confusing the
UI.
So my role was to translate messy real-world scenarios into clear
error rules, ensure we had a consistent error model, and validate
that downstream systems behaved predictably when things weren’t
perfect… which is most of the time.
Question:
APIs expose sensitive data, especially in Wealth Management. How
did you handle security and data privacy considerations as a BA for
your Data Services APIs?
Answer (sample):
“In wealth management, APIs can easily leak more than they
should if we’re not careful, so I was very hands-on about security
and privacy in the Data Services project.
Our Data Services layer exposed things like client personal details,
investment holdings, and transaction history. Here’s what I focused
on as a BA:
1. Classify data with InfoSec and Compliance
I worked with the InfoSec and Compliance teams to classify
the fields in our canonical model:
a. Highly sensitive: SIN, tax IDs, full DOB, contact details.
b. Regulated: KYC status, risk profile.
c. Business-use only: internal segment codes, advisor
commission attributes.
This classification drove which fields could appear in which API and
for which consumer type.
2. Define consumer-specific views / scopes
Using that classification, we defined:
a. Advisor scope: full view for authenticated advisors
through the advisor desktop.
b. Client scope: limited view for the online banking / client
portal.
c. System-to-system scope: for internal reporting with
stronger controls.
As a BA, I documented:
d. For /clients/{clientId}, which fields are visible under
which OAuth scope.
e. Which APIs are never exposed externally (e.g., internal
reconciliation APIs).
3. Masking and tokenization rules
For example, we decided:
a. Show masked account numbers in the client portal
(XXXX-1234) but the full number in the advisor desktop.
b. Do not expose tax IDs via Data Services at all; only legacy
batch interfaces could access them.
I wrote explicit requirements like:
“For the clientPortal consumer, field accountNumber must always
be masked except last 4 digits, regardless of advisor’s
permissions.”
4. Involve security early in design, not at the end
Instead of waiting for a ‘security review’ at the end, I brought
security architects into our API design workshops.
a. When we discussed a new /transactions endpoint, we
aligned early on retention, logging, and masking rules.
b. They helped ensure auditability: we included traceId and
avoided logging full payloads with PII in plain text.
5. Test security scenarios in UAT
I made sure we had UAT scenarios like:
a. A client logging into the portal and trying to access
another client’s account via manipulated IDs.
b. An advisor losing access to a book of business and
verifying that APIs no longer return those accounts for
that advisor.
So even though I’m not a security engineer, as a BA I was the one
connecting the dots between business rules, regulatory obligations,
and how they actually translate into field-level rules, scopes, and
masking in the APIs.
Question:
Walk me through how you used API specifications (like
Swagger/OpenAPI) as a BA in your Data Services project. How did
you ensure both business and technical stakeholders understood
and agreed on the contract?
Answer:
“In the Data Services project, Swagger/OpenAPI became almost
like a living contract between business, dev, and downstream
teams. I used it not just as a technical artifact, but as a
collaboration tool.
Here’s how:
1. Start from business perspectives, then refine the spec
For a new /transactions API, I began with a simple business-
friendly view:
a. What does an advisor need to see? (date, amount, type,
status, security, account)
b. What does compliance care about? (source system,
booking entity, channel, regulatory flags)
I drafted this first in a plain table (field name, description, sample
values). Once we were aligned at the business level, I worked with
the dev lead to convert it into an OpenAPI spec:
c. Defined field types, enums, and required/optional fields.
d. Added examples for complex structures like nested
security objects.
2. Use Swagger UI in workshops
Instead of sending PDFs, I would bring Swagger UI into the
workshop.
a. Show the /transactions endpoint.
b. Walk through the sample request and response.
c. Ask the advisor or reporting stakeholder: “If you saw this
in your screen or report, would that be enough?”
That visual walkthrough helped non-technical users react to
something concrete. A classic example:
d. An advisor pointed out that just seeing ‘BUY’ wasn’t
enough. They wanted a channel field (e.g., ‘Online’,
‘Advisor-assisted’), which we then added to the spec.
3. Use the spec to drive test cases and acceptance criteria
I derived UAT scenarios directly from the API spec:
a. For each field and enum, we had at least one scenario.
b. For pagination parameters (page, size) in /transactions, I
created tests to verify the correct count and navigation.
This made UAT less about ‘random clicking’ and more about
verifying the contract.
4. Keep the spec updated with real changes, not wishful thinking
Whenever developers proposed a change (‘we’ll return this
additional field’ or ‘we’re deprecating that enum’), I insisted:
a. First, update the OpenAPI spec.
b. Then, communicate to consumers and adjust test cases.
There was one case where a dev changed a field from string to
number for performance reasons. In a spec review, we caught it
early and realized that one downstream system stored it as a string.
We avoided a production issue because the change was surfaced in
Swagger before release.
5. Bridge language between business and tech
I’d often translate:
a. Business speak like “we need to know if a transaction is
pending settlement”
into
b. A spec field settlementStatus with enum values like
PENDING, SETTLED, FAILED.
By keeping those descriptions clear in the spec (not just field
names), it became a single reference point everyone trusted.
So, as a BA, I didn’t treat Swagger as ‘developer territory’. I used it
as a shared contract and conversation starter, making sure the APIs
we shipped actually reflected what wealth management
stakeholders needed and what downstream consumers could
safely rely on.