APIs & System Integration
A practical BA revision guide for understanding how systems communicate, what data is exchanged, what validations apply, how failures are handled, and how integrations are documented and tested.
As a BA, you are not expected to code APIs, but you are expected to understand integration behavior well enough to document requirements, ask the right questions, identify failure scenarios, support data mapping, and help QA validate the end-to-end flow.
What is an API?
An API, or Application Programming Interface, allows two software systems to communicate with each other.
An API is a controlled way for one system to request, send, update, or receive data from another system.
- A mobile app uses an API to get account details from a banking system.
- An application portal uses an API to send submitted application data to an external processing system.
Think of an API as a messenger between systems.
What is System Integration?
System integration means connecting two or more systems so they can exchange data or perform a business process together.
System integration is the process of connecting systems so data and business actions flow correctly between them.
| System A | Integration | System B |
|---|---|---|
| Online Order System | Sends order details | Warehouse System |
| HR System | Sends employee data | Payroll System |
| Application Portal | Sends application data | Document Management System |
| CRM System | Sends customer data | Reporting System |
API vs Integration
| Topic | Meaning | Example |
|---|---|---|
| API | A technical method used by systems to communicate | REST API endpoint sends customer data |
| Integration | The full business and technical process connecting systems | Send, validate, receive, handle errors, log, retry, and confirm success |
API is one way to achieve integration. Integration is the bigger business process.
Why BAs Need to Understand APIs
A BA does not usually write API code, but the BA must define and validate integration behavior.
Why do these systems need to connect?
Which system sends the data?
Which system receives the data?
What event starts the integration?
What fields are sent and received?
What data is required, accepted, rejected, or transformed?
What should happen when the API succeeds?
What should happen when the API fails?
What messages, logs, retries, or notifications are needed?
Who or what is allowed to access the API?
What integration activity should be tracked?
What positive, negative, and failure scenarios should be validated?
As a BA, I do not need to write API code, but I need to document the business purpose, source and target systems, field mapping, trigger, validation rules, success response, failure handling, retry behavior, audit needs, and test scenarios.
Common Types of System Integration
Real-Time Integration
Data is sent immediately when an event happens.
User submits a form and the system immediately sends data to another system.
- Immediate response is needed.
- User is waiting for confirmation.
- Business action depends on external response.
Batch Integration
Data is sent in groups at scheduled times.
Every night, approved transactions are sent to a finance system.
- Real-time response is not needed.
- Large volume of data is processed.
- Scheduled reporting or reconciliation is needed.
File-Based Integration
Systems exchange files such as CSV, XML, Excel, or flat files.
System A exports a CSV file and System B imports it daily.
- Legacy systems are involved.
- APIs are not available.
- Large data transfer is needed.
API-Based Integration
Systems exchange data through API calls.
System A sends a JSON request and receives a JSON response.
- Real-time or near real-time communication is needed.
- Systems support modern APIs.
- Structured request and response are required.
Manual Integration
Users manually export or import data between systems.
User downloads an Excel file from one system and uploads it into another.
- Automation is not available yet.
- A temporary process is needed.
- Data volume is low.
Basic API Terms
The specific URL or API location where a request is sent.
/api/customers or /api/orders/{orderId}The data sent to the API from the source system.
The data returned by the API after processing the request.
The actual business data sent in the request or response.
A structured data format commonly used in APIs.
{
"caseId": "C1001",
"status": "Open",
"priority": "High"
}Another data format used for system-to-system data exchange, especially in legacy or enterprise systems.
<case>
<caseId>C1001</caseId>
<status>Open</status>
</case>REST API Basics
Most modern APIs follow REST API patterns. A BA should understand the common HTTP methods.
| Method | Meaning | BA Example |
|---|---|---|
| GET | Retrieve data | Get customer details |
| POST | Create new data | Create a new request |
| PUT | Replace or update full data | Update a full profile |
| PATCH | Partially update data | Update only status |
| DELETE | Delete data | Delete a document |
Read = GET, Create = POST, Update = PUT/PATCH, Delete = DELETE.
In REST APIs, GET retrieves data, POST creates data, PUT or PATCH updates data, and DELETE removes data.
HTTP Status Codes
| Status | Meaning | BA Interpretation |
|---|---|---|
| 200 | OK | Request successful |
| 201 | Created | New record created |
| 400 | Bad Request | Request data is invalid |
| 401 | Unauthorized | User or system is not authenticated |
| 403 | Forbidden | User or system does not have permission |
| 404 | Not Found | Requested record or API is not found |
| 409 | Conflict | Duplicate or conflicting data |
| 500 | Server Error | Target system failed |
| 503 | Service Unavailable | External system temporarily unavailable |
Status codes help BAs and QA define success, validation, access, duplicate, unavailable, and server failure scenarios.
API Authentication and Authorization
Authentication
Verifies who the user or system is.
- Login credentials
- API key
- Token
- OAuth
Authorization
Verifies what the user or system is allowed to do.
- Can view data
- Can create records
- Can update records
- Can access only assigned records
A unique key used to identify the calling application.
A temporary credential used to access the API.
A secure authorization framework commonly used for token-based access.
Authentication verifies identity, while authorization verifies permission. For integration requirements, a BA should clarify which systems are allowed to call the API, what data they can access, and what actions they can perform.
API Request and Response Example
Scenario: A system needs to create a customer in another system.
{
"firstName": "John",
"lastName": "Smith",
"email": "john.smith@email.com",
"phone": "5551234567"
}{
"status": "success",
"customerId": "CUST1001",
"message": "Customer created successfully"
}{
"status": "error",
"errorCode": "EMAIL_DUPLICATE",
"message": "Email already exists"
}| Area | BA Requirement |
|---|---|
| Mandatory Fields | First name, last name, email |
| Validation | Email must be unique |
| Success Behavior | Store returned customer ID |
| Error Behavior | Show duplicate email message |
| Audit | Log request timestamp and response status |
| Retry | Do not retry duplicate email error |
| Testing | Test success, missing email, invalid email, duplicate email, API unavailable |
Swagger / OpenAPI
Swagger, also called OpenAPI, is API documentation that describes API behavior.
- API endpoints
- Request fields
- Response fields
- Required fields
- Data types
- Error codes
- Authentication method
- Example request and response
A BA can review Swagger to understand what fields are required, what response is expected, what errors need to be handled, and what scenarios QA should test.
I have used Swagger or API documentation to understand endpoints, request and response structures, required fields, data types, and error responses, then worked with technical teams to document integration requirements and test scenarios.
Postman
Postman is a tool used to test APIs.
- Send API requests
- View API responses
- Validate status codes
- Test request payloads
- Check success and error scenarios
A BA does not need to be a Postman expert, but understanding request, response, status code, and error behavior is useful during API validation and testing discussions.
I understand the basics of Postman for API validation. I can review request and response payloads, status codes, and error messages to support requirement validation and testing discussions.
Data Mapping in Integration
Data mapping defines how fields from one system map to another system.
| Source System Field | Target System Field | Transformation |
|---|---|---|
| first_name | FirstName | Direct mapping |
| last_name | LastName | Direct mapping |
| dob_text | DateOfBirth | Convert to MM/DD/YYYY |
| status_code | Status | A = Active, I = Inactive |
| phone | PhoneNumber | Remove special characters |
BA Responsibility: document source field, target field, data type, mandatory or optional status, transformation rule, validation rule, default value, and business notes.
API Integration Requirement Template
| Area | Questions to Answer |
|---|---|
| Business Purpose | Why is this integration needed? |
| Source System | Which system sends the data? |
| Target System | Which system receives the data? |
| Trigger | What starts the API call? |
| Direction | Is the data flow one-way or two-way? |
| Frequency | Is it real-time, batch, scheduled, or manual? |
| Data Fields | What fields are exchanged? |
| Data Mapping | How do source fields map to target fields? |
| Validations | What data is required or rejected? |
| Success Response | What happens when API succeeds? |
| Failure Response | What happens when API fails? |
| Error Handling | What message, log, retry, or notification should occur? |
| Security | What authentication and authorization rules apply? |
| Audit Logging | What should be logged? |
| Retry Logic | Should failed calls be retried? |
| Notifications | Should users or admins be notified? |
| Testing | What positive and negative scenarios are needed? |
For integrations, documenting only the field mapping is not enough. A BA must also capture trigger, frequency, success behavior, error handling, retry logic, security, audit logging, and test scenarios.
Integration Trigger Types
User clicks Submit
Record status changes to Approved
Every night at 12 AM
User uploads CSV file
New record is created
Admin clicks Send to External System
Payment is completed
BA Question: What event should trigger the integration?
One-Way vs Two-Way Integration
One-Way Integration
Data flows from System A to System B.
Application system sends approved applications to reporting system.
Two-Way Integration
Data flows between both systems.
System A sends a request to System B, and System B returns status updates back to System A.
BA Question: Does the source system only send data, or does it also need to receive updates back?
Synchronous vs Asynchronous Integration
| Type | Meaning | Example | Used When |
|---|---|---|---|
| Synchronous | System waits for immediate response | Validate address before user continues | Immediate confirmation is needed |
| Asynchronous | System sends data and processes response later | Nightly batch file processing | High volume or background processing is acceptable |
Synchronous integration requires an immediate response, while asynchronous integration allows the system to send data and process the response later. A BA should clarify whether the business process requires real-time confirmation or can support delayed processing.
Success and Failure Scenarios
Success Scenario
API accepts request, creates or updates record, returns confirmation, and source system stores the returned response.
BA Questions
- What should the user see?
- What should be logged?
- Should the system retry?
- Should admin or support be notified?
- Can the user resubmit?
- Should the failed record remain pending?
| Failure | Expected Handling |
|---|---|
| Required field missing | Show validation error |
| Invalid format | Reject request |
| Duplicate record | Show duplicate message |
| Unauthorized access | Show access denied and log error |
| External system unavailable | Retry or show temporary failure |
| Timeout | Log failure and retry if configured |
| Server error | Notify support or admin |
| Partial failure | Show which records failed |
Error Handling and Retry Logic
Error Handling
Defines what happens when integration fails.
- Display user-friendly error message.
- Log technical error.
- Save failed request for retry.
- Notify support team.
- Allow manual resubmission.
- Mark record as failed.
- Prevent duplicate submission.
Retry Logic
Defines whether the system should attempt again after failure.
If the external system is unavailable, retry every 15 minutes up to 3 attempts.
- Which errors should be retried?
- Which errors should not be retried?
- How many retry attempts?
- How often should retry happen?
- What happens after final failure?
- Who gets notified?
Do not retry validation errors like missing mandatory fields. Retry is useful for temporary issues like timeout or service unavailable.
Audit Logging in Integration
For integrations, logging is critical because teams need to trace what was sent, when it was sent, whether it succeeded, and what failed.
- What request was sent?
- When was it sent?
- Who or what triggered it?
- What response was received?
- Was it successful or failed?
- What error occurred?
- Was retry attempted?
- Who resolved it?
- Was data changed?
I ensure integration requirements include audit logging so the team can trace what was sent, when it was sent, whether it succeeded, and what error occurred if it failed.
API Testing Scenarios for BA/QA
Positive Scenarios
- Valid request returns success response.
- Required fields are accepted.
- Confirmation ID is returned.
- Source system stores target system response.
- Audit log is created.
Negative Scenarios
- Missing mandatory field.
- Invalid data format.
- Duplicate data.
- Unauthorized request.
- Forbidden access.
- Record not found.
- API timeout.
- External system unavailable.
- Server error.
- Invalid token.
- Expired token.
Boundary Scenarios
- Maximum field length.
- Minimum field length.
- Maximum records in batch.
- Special characters.
- Date format.
- Large payload.
- Empty optional fields.
Integration-Specific Scenarios
- Retry after timeout.
- No retry for validation error.
- Partial success in batch.
- Failure notification.
- Duplicate prevention.
- Idempotency behavior.
Idempotency
Idempotency means that if the same API request is submitted multiple times, it should not create duplicate results.
If a user clicks Submit twice, the system should not create two duplicate records.
For integrations involving create or submit actions, I clarify duplicate prevention or idempotency behavior so repeated requests do not create duplicate records.
This is an advanced but useful concept for Technical BA interviews.
Common API / Integration Questions a BA Should Ask
- What business process needs integration?
- Why do these systems need to communicate?
- What business value does the integration provide?
- What happens if integration is not available?
- What is the source system?
- What is the target system?
- Is the data flow one-way or two-way?
- Is the integration real-time, batch, or manual?
- What triggers the integration?
- What fields are sent?
- Which fields are mandatory?
- What is the data format?
- What are the valid values?
- Are transformations needed?
- Is source-to-target mapping required?
- What validations happen before sending data?
- What validations happen in the target system?
- What happens if validation fails?
- Should the user be able to correct and resubmit?
- What happens if the API is unavailable?
- What happens if the request times out?
- What happens if duplicate data is sent?
- Should the system retry?
- Should the support team be notified?
- Should failure be visible to users?
- How will systems authenticate?
- What permissions are required?
- Is sensitive data exchanged?
- Should data be encrypted?
- Should access be role-based?
- What should be logged?
- Who should be able to view logs?
- How long should logs be retained?
- Should failed integrations be reportable?
- What are success scenarios?
- What are failure scenarios?
- What test data is needed?
- How do we validate request and response?
- How do we validate logs, retries, and notifications?
How to Document API Requirements as a BA
| Section | Example |
|---|---|
| Integration Name | Submit Application to External System |
| Business Purpose | Send approved application data for downstream processing |
| Source System | Application Portal |
| Target System | External Processing System |
| Trigger | User clicks Submit or status changes to Approved |
| Frequency | Real-time |
| Direction | One-way |
| API Method | POST |
| Request Fields | Name, DOB, Email, Status |
| Response Fields | Confirmation ID, Status, Message |
| Validation Rules | Email required, DOB valid date |
| Success Handling | Store confirmation ID and mark as Sent |
| Error Handling | Display error and log failure |
| Retry Logic | Retry timeout errors 3 times |
| Security | Token-based authentication |
| Audit Logging | Log request, response, timestamp, status |
| Test Scenarios | Success, missing fields, invalid token, timeout, duplicate |
Sample User Story for API Integration
“As a business user, I want the system to send approved request details to the external processing system so that downstream processing can begin without manual data entry.”
Given a request has been approved, When the system triggers the integration, Then the request details shall be sent to the external system.
Given the external system successfully accepts the request, When a success response is returned, Then the source system shall store the confirmation ID and mark the integration status as Sent.
Given the external system is unavailable, When the integration fails due to timeout or service error, Then the system shall log the failure and retry based on configured retry rules.
Given the request contains invalid mandatory data, When the integration is triggered, Then the system shall not send the request and shall display or log validation errors.
Sample Data Mapping for API
| Source Field | Target Field | Data Type | Mandatory | Transformation | Validation |
|---|---|---|---|---|---|
| firstName | first_name | String | Yes | Direct | Max 50 characters |
| lastName | last_name | String | Yes | Direct | Max 50 characters |
| dob | date_of_birth | Date | Yes | Convert to YYYY-MM-DD | Cannot be future date |
| email_address | String | Yes | Lowercase | Valid email format | |
| phone | phone_number | String | No | Remove dashes | 10 digits |
| status | request_status | String | Yes | Map Approved = A | Must be valid status |
Common Mistakes BAs Make with Integrations
For integrations, documenting only the field mapping is not enough. A BA must also capture trigger, frequency, success behavior, error handling, retry logic, security, audit logging, and test scenarios.
Interview Answer Bank
Top 1% BA Language
Say this, not that.
I know APIs
I understand API behavior from a business and requirements perspective.
I document integrations
I define source and target systems, trigger, data mapping, validations, success response, failure behavior, retry logic, security, audit logging, and test scenarios.
I check fields
I validate request and response payloads, mandatory fields, data types, transformations, and business rules.
I support testing
I help QA identify positive, negative, boundary, timeout, authentication, duplicate, retry, and audit log scenarios.
I talk to developers about APIs
I clarify integration behavior, feasibility, dependencies, and error handling with technical teams.
I understand API failures
I document what users see, what gets logged, whether retry is needed, and how support teams are notified.
Final Master Answer
“As a BA, I understand APIs and system integrations from a business and requirements perspective. An API allows systems to communicate, while integration is the full process of exchanging data between systems. For integration requirements, I identify the business purpose, source and target systems, trigger, frequency, direction of data flow, request and response fields, data mapping, validations, success and failure behavior, error handling, retry logic, security, audit logging, and testing scenarios. I work with technical teams to confirm feasibility and with QA to ensure both positive and negative integration scenarios are covered.”
Ready to Practice?
Use this guide to revise API and system integration concepts, prepare Technical BA interview answers, and explain how you document integration requirements, data mapping, error handling, retry logic, audit logging, and testing scenarios.
Back to BA Skills Resources