API Master Interview Guide for Senior
Business Analysts – 20 Scenario,
Situational, and Technical Q&A
Diwakar Singh
Q1. During API discovery, backend developers inform you that a
3rd-party KYC provider’s API doesn’t support batch requests,
but your business stakeholders expect onboarding 500
customers at once. How would you handle this?
Answer:
Context:
In the Client Onboarding (KYC Automation) project for a retail bank,
our goal was to reduce onboarding time from 5 days to 1 day using
APIs integrated with a 3rd-party provider (e.g., Trulioo).
Approach:
1. Gap Identification:
I confirmed via Swagger that /verify endpoint accepted only
one record per request (no array payload).
2. Business Clarification:
I explained to stakeholders that bulk verification would cause
API throttling and increase latency.
3. Options Explored:
a. Option 1: Implement asynchronous queue (Kafka topic)
to process individual requests in parallel.
b. Option 2: Negotiate with vendor for a bulk endpoint (not
feasible in short term).
4. Decision:
Proposed asynchronous message queue + retry mechanism
to meet business SLA without changing vendor API.
Outcome:
Reduced KYC processing to under 10 minutes per 100 users while
keeping vendor within rate limits.
Q2. Suppose a new regulatory change requires you to include
“Source of Funds” in the AML screening API. What steps would
you take as a BA?
Answer:
1. Impact Analysis:
a. Check existing /screen-customer API request model —
confirm field addition required in JSON payload.
b. Review downstream systems consuming response (e.g.,
Data Warehouse, Case Management).
2. Stakeholder Coordination:
a. Meet AML Ops and Compliance to clarify definition and
data source for “SourceOfFunds.”
b. Confirm allowed values (Salary, Business Income,
Inheritance, etc.).
3. Change Documentation:
a. Update API Contract in Swagger, data dictionary, and
mapping sheet.
b. Raise change request in Confluence/JIRA with clear
traceability.
4. Testing Readiness:
a. Define UAT scenarios for valid, invalid, and null inputs.
b. Validate payload and API response using Postman
collections.
Outcome:
Regulatory audit passed without exceptions, and data lineage was
documented end-to-end.
Q3. How do you facilitate discussions between API developers
and business stakeholders when both use different
terminologies?
Answer:
Example:
In Insurance Claim Automation project (Cigna integration),
business users said “policy lookup,” while developers spoke in
terms of /getPolicyDetails API.
My Facilitation Strategy:
1. Use Visuals:
I created an API Interaction Diagram showing which endpoints
were called in each business step.
2. Translate Terms:
Built a “Glossary” table mapping business terms → API
operations (e.g., Policy Lookup → GET /policy/{id}).
3. Bridge Gaps:
Used Postman demo sessions to show actual
request/response so non-technical stakeholders could see
data flow.
4. Outcome:
Eliminated miscommunication, ensuring all parties aligned on
both business process and API behavior.
Q4. A testing team reports inconsistent response times for the
/fundTransfer API. Business insists this impacts customer
experience. How would you approach this?
Answer:
Step 1 – Verify Performance Metrics:
Use New Relic dashboards to view response latency — confirmed
spikes >2 seconds during peak hours.
Step 2 – Root Cause Analysis:
• Checked database query time (fine).
• Discovered downstream AML check API dependency causing
80% of delay.
Step 3 – Stakeholder Alignment:
Explained to business that core API wasn’t the problem; the
chained API call added latency.
Step 4 – Resolution:
Recommended asynchronous call with callback notification for
AML screening to decouple transfer flow.
Step 5 – Result:
Average response time dropped from 2.4s → 0.7s, while maintaining
compliance flow asynchronously.
Q5. How do you validate API requirements before development
starts?
Answer:
I follow a 4-step validation checklist:
1. Confirm Resource Model:
Ensure each endpoint represents a valid business resource
(e.g., /customers, /transactions).
2. Verify CRUD Alignment:
Each operation (GET, POST, PUT, DELETE) should match the
action type in user stories.
3. Check Data Contract:
Review Swagger for correct field types, mandatory vs optional
parameters, and example payloads.
4. Simulate Request:
Use mock servers (e.g., SwaggerHub, Postman mock server)
to validate sample data against stakeholder expectations.
Example:
In the Loan Origination System, I simulated /calculateEMI request
with loanAmount=500000, tenure=24, rate=8% — verified correct
EMI response before build. This avoided major rework later.
Q6. What is your approach for documenting and mapping APIs in
a complex integration landscape?
Answer:
Example from Capital Markets – Security Reference Data
System Integration
1. Create API Catalog:
Document all endpoints with source → target → purpose (e.g.,
Bloomberg → Reference DB → Downstream Apps).
2. Define Data Mapping Sheet:
Include attributes like ISIN, CUSIP, IssueDate, MaturityDate,
mapping to JSON response.
3. Version Control:
Maintain version history (v1, v2) and deprecation timelines in
Confluence.
4. Visual Representation:
Create Sequence Diagrams using PlantUML to show call order
and response dependencies.
5. Validation:
Cross-check using API Gateway logs (e.g., Apigee, Kong).
Outcome:
Developers, testers, and architects used the same source of truth
for integration references, reducing defects by 35%.
Q7. How do you handle backward compatibility when an API
version is upgraded?
Answer:
Example:
In Retail Banking API Gateway Migration from v1 to v2, response
field accountType was renamed to acctType.
Actions Taken:
1. Impact Analysis:
Identified all downstream consumers using v1 (CRM,
Reporting, Mobile App).
2. Parallel Versioning:
Maintained both versions temporarily with deprecation notice
(HTTP 299 header).
3. Communication:
Sent out API Consumer Notification Document with change
details and test window.
4. Testing & Transition:
Assisted QA in regression testing both versions until
consumers migrated fully.
Outcome:
Seamless transition without breaking production dependencies.
Q8. How do you ensure security and compliance in API projects
from a BA standpoint?
Answer:
Example: Payment Gateway Integration
1. Authentication:
Confirm APIs use OAuth 2.0 or JWT — captured as Non-
Functional Requirement in BRD.
2. Data Masking:
PII fields like PAN, SSN, or card number masked in API
response (XXXX-XXXX-1234).
3. Audit Trail:
Logged every API call (timestamp, client ID, status code) for
regulatory audit.
4. Error Handling:
Defined standardized error codes (e.g., 400_BAD_REQUEST,
401_UNAUTHORIZED, 500_INTERNAL_ERROR).
5. Compliance Validation:
Worked with InfoSec to ensure PCI-DSS and GDPR controls
were applied.
Result:
Passed compliance audit in first review with zero API data leakage
incidents.
Q9.
You’re integrating a new Customer Verification API into your
onboarding platform, but the vendor documentation is incomplete
and no Postman collection is available. How do you proceed?
Answer (Structured):
• Context:
In an Account Opening API integration with Equifax, our
onboarding system needed /verifyIdentity and /getRiskScore
endpoints, but vendor docs lacked payload examples.
• Approach:
o Engage Vendor: Request minimal working sample JSONs
and response schema.
o Reverse-Engineer: Capture live API traffic via mock
server (e.g., SwaggerHub mock, Postman interceptor).
o Collaborate: Conduct working session with vendor tech
lead to map fields (e.g., nationalId, riskLevel,
matchScore).
o Document: Create provisional Swagger spec and
validate with Dev Lead and QA.
• Outcome:
Built a BA-approved interim Swagger for developers to mock
early — reduced onboarding delay by two sprints.
Q10.
During UAT, testers report that /accountTransfer API intermittently
returns HTTP 500 errors. The dev team claims “it’s a backend
issue.” What would be your next steps as a BA?
Answer (Structured):
• Analysis:
o 500 errors indicate server exceptions, but as BA, focus on
reproducing patterns.
• Approach:
o Collect Evidence: Pull Postman logs and request IDs.
o Correlate Inputs: Found pattern — only fails when
transferAmount > $10,000.
o Business Rule Check: Confirmed business rule requires
additional AML validation API call for high-value transfers.
o Outcome:
Discovered missing AML API chaining. Raised defect and
updated API sequence diagram to reflect new
dependency.
• Result:
API stabilized after linking /amlCheck before
/accountTransfer, and SLA improved 30%.
Q11.
Your project team is building APIs for Loan Application Status.
Product Owner asks to “make all data available in one API.” How do
you balance business convenience vs API best practice?
Answer:
• Context:
Loan module had multiple microservices — /loanDetails,
/paymentHistory, /collateralInfo.
• Steps:
o Educate Stakeholders: Explain single-endpoint design
increases payload size and latency.
o Suggest Solution: Introduce API Orchestration Layer
(aggregator service).
o Define Contract: Create a composite API /loanSummary
calling underlying services sequentially.
o Outcome:
Business retained single endpoint experience,
developers maintained modularity.
Q12.
Developers are requesting business sign-off for a new header X-
Client-ID in all API calls. Business stakeholders don’t understand its
need. How would you handle this?
Answer:
• Explanation Bridge:
o Translate: “This header is not business data — it helps
trace who is calling the API.”
o Create simple diagram showing API Gateway →
Downstream → Audit Logs.
• Approach:
o Host quick walkthrough explaining compliance
traceability (audit logs).
o Capture this in Non-Functional Requirements (NFRs)
under Security and Logging.
o Obtain business approval citing compliance audit
benefits (SOX, PCI-DSS).
• Outcome:
Stakeholders approved addition; it later enabled fraud
investigation team to trace API misuse in seconds.
Q13.
A third-party API vendor updates their schema without notice,
breaking your integration. How do you ensure such incidents are
avoided next time?
Answer:
• Immediate Fix:
o Roll back to last stable schema and patch urgent
endpoints.
• Preventive Actions:
o Add Schema Contract Validation: Implement
automated schema check via API Gateway (e.g., Apigee
policy).
o Set SLA in Vendor Agreement: Mandatory 30-day notice
for contract changes.
o Version Control: Enforce /v1, /v2 URI versioning and
deprecation timeline.
o Governance: Include API contract change review in
sprint ceremonies.
• Example:
In Insurance Claim APIs, this process prevented production
outages when vendor added new optional field
beneficiaryCode.
Q14.
Business wants to capture additional fields (maritalStatus,
preferredLanguage) during registration, but backend API is managed
by another team. How do you ensure alignment?
Answer:
1. Impact Analysis:
a. Verify if existing /register API supports new attributes.
2. Interface Discussion:
a. Facilitate joint BA–Tech–Backend workshop to define
schema change impact (DB, validation rules,
dependencies).
3. Change Control:
a. Create API Change Request document with payload
examples, version, and backward compatibility plan.
4. Outcome:
a. Additional fields released in v2; legacy consumers
continued using v1 without regression.
Q15.
Explain how you validate an API’s readiness for UAT as a Business
Analyst.
Answer:
• Checklist:
o Swagger Spec reviewed and signed off.
o Test Data created for all positive and negative scenarios.
o Postman Collection or Newman scripts available.
o Mock environment tested for 200, 400, 404, 500
responses.
o Contract validation: fields, data types, mandatory rules
verified.
• Example:
In Digital Wallet Project, validated /addCard and /getBalance
APIs using mock payloads and ensured encryption headers in
test environment matched production settings.
Q16.
How do you analyze an API payload when troubleshooting data
mismatches between two systems?
Answer:
• Context:
Data mismatch between CRM and Core Banking systems
using /customerProfile API.
• Steps:
o Extract both payloads via Postman and API Gateway logs.
o Compare JSON fields line-by-line (e.g., contactNumber,
email).
o Identify transformation logic in middleware (e.g.,
Mulesoft map changing field name phone →
contact_number).
o Collaborate with DevOps to adjust mapping script.
• Outcome:
Eliminated 15% of duplicate contact cases and aligned both
systems’ data definitions.
Q17.
What’s your approach to designing error codes for APIs as a BA?
Answer:
• Principles:
o Standardize and categorize errors (Client, Server,
Business).
o Provide descriptive message, trace ID, and remediation
guidance.
• Example:
In Payments Gateway Project:
400_BAD_REQUEST → Missing or invalid parameters
401_UNAUTHORIZED → Token expired
422_UNPROCESSABLE → Business validation failed
500_INTERNAL_ERROR → Unexpected exception
o Defined in Error Handling Matrix within FRD.
• Outcome:
Reduced repetitive incident tickets by 40% because users
understood root cause from API response.
Q18.
How would you document API dependencies in a large system with
50+ microservices?
Answer:
• Technique:
o Maintain API Inventory Sheet: Endpoint, source system,
consumer, purpose, SLA.
o Create System Context Diagram showing
upstream/downstream flows.
o For critical flows, add Sequence Diagrams using
PlantUML.
o Keep API dictionary and version mapping in Confluence.
• Example:
In Capital Markets Securities Data Migration, created
dependency matrix linking Bloomberg feed APIs with Risk
Engine and Reporting modules.
Q19.
Explain your approach to handling pagination and filtering in large
data APIs.
Answer:
• Scenario: /transactions API returning 50,000 records caused
timeouts.
• Solution:
o Added query parameters ?page=1&limit=1000.
o Introduced filters like ?fromDate=2024-01-
01&toDate=2024-01-31.
o Educated stakeholders on trade-off between
convenience and performance.
• Outcome:
Reduced payload size, improved response time from 8s →
1.2s.
Q20.
How do you ensure security compliance in open APIs (public
endpoints)?
Answer:
• Steps:
o Implement OAuth 2.0 with client credentials grant.
o Enforce rate limiting and IP whitelisting.
o Mask PII in logs and payloads.
o Validate all input parameters via schema validation.
• Example:
In Open Banking APIs for a fintech client, these controls
ensured PSD2 compliance and zero security incidents post-
launch.