Get Proposal Reports by Proposal ID¶

ID: UC-WFP-PROPSL-D002
Complexity: Basic
Description: Retrieve proposal change reports and audit trail for a specific proposal using the WFP proposal API
Scenario: A business user or administrator needs to retrieve the complete audit trail and change history for a specific proposal to review modifications, track user activities, and ensure compliance with organizational policies
Business Value: Enables comprehensive proposal audit trails, supports compliance requirements, facilitates change tracking and analysis, and provides transparency in proposal management processes

Prerequisites¶

Valid API key for WFP API
Access to WFP API environment
Proposal ID for existing proposal
Understanding of pagination concepts

Steps¶

1. Get Proposal Reports (Basic)¶

Retrieve the first page of proposal change reports for a specific proposal

Endpoint: GET /api/v1/ext/proposals/{proposal-id}/report

HTTP Request

curl -X GET 'https://{base-url}/api/v1/ext/proposals/{proposal-id}/report' 
  -H 'x-api-key: YOUR_API_KEY' 
  -H 'Content-Type: application/json'

Expected Response: HTTP 200 with paginated proposal change reports

Notes: Replace {proposal-id} with the actual proposal ID. This returns the first 1000 records by default

2. Get Proposal Reports with Pagination¶

Retrieve proposal change reports with custom pagination parameters

Endpoint: GET /api/v1/ext/proposals/{proposal-id}/report

HTTP Request

curl -X GET 'https://{base-url}/api/v1/ext/proposals/{proposal-id}/report?page=0&size=50' 
  -H 'x-api-key: YOUR_API_KEY' 
  -H 'Content-Type: application/json'

Expected Response: HTTP 200 with paginated proposal change reports (50 records per page)

Notes: Use pagination parameters to control the number of records returned. page=0 is the first page, size=50 limits results to 50 records

3. Get Additional Pages¶

Retrieve subsequent pages of proposal change reports

Endpoint: GET /api/v1/ext/proposals/{proposal-id}/report

HTTP Request

curl -X GET 'https://{base-url}/api/v1/ext/proposals/{proposal-id}/report?page=1&size=50' 
  -H 'x-api-key: YOUR_API_KEY' 
  -H 'Content-Type: application/json'

Expected Response: HTTP 200 with second page of proposal change reports

Notes: Increment the page parameter to get subsequent pages. Check the ‘last’ field in the response to determine if more pages exist

Error Scenarios¶

Invalid Proposal ID (400): Verify that the proposal ID is valid Recovery: Contact Nakisa Support team to verify the proposal ID

Invalid Pagination Parameters (400): Validate the page and size parameters are within acceptable ranges Recovery: Use page >= 0 and size between 1 and 1000

Unauthorized Access (403): Verify that your API key has the necessary permissions to access proposal reports Recovery: Contact the Nakisa Support team to grant appropriate permissions

Proposal Not Found (422): Verify that the proposal ID exists and you have access permissions Recovery: Check proposal ID validity and ensure proper authorization

Rate Limit Exceeded (429): Too many requests in a short time period Recovery: Implement exponential backoff and retry after the rate limit window expires

Best Practices¶

Implement proper pagination handling to retrieve all report data
Use appropriate page sizes based on your application needs (50-100 records per page recommended)
Cache report data when possible to reduce API calls
Implement retry logic for failed requests with exponential backoff
Log report access for audit purposes
Handle empty responses gracefully when no changes exist for a proposal
Parse the response structure to extract meaningful change information
Monitor API rate limits and implement appropriate throttling

Performance Tips¶

Use smaller page sizes (50-100) for better performance with large datasets
Implement client-side caching to avoid redundant API calls
Consider implementing background jobs for large report retrieval
Use the ‘last’ field in pagination response to optimize navigation