Overview
This guide outlines the mandatory test scenarios for integrating with the MMR-SASK API. You must complete all test scenarios in the test environment before moving to production.Once you complete all test cases, contact us to proceed with production deployment.
Test Environment
Use the development server for all testing:Test Scenarios
- Report Natural Person Account
- Report Legal Entity Account
Natural person accounts are reported with owner type
F. This flow covers account creation, updates, and representative management.What you report for a natural person account:- Account details - IBAN, currency, account type, open/close dates
- Owner information - Name, surname, birth date, address, nationality
- Identification - Personal code or foreign identification code, document type and number
- Representatives - Individuals authorized to manage the account on behalf of the owner
- Beneficial owners (UBO) are not reported for natural person accounts.
- Representatives can only be natural persons.
Test Case 1: Create Account
Test Case 1: Create Account
Objective: Report a newly opened account with owner and representatives to the tax authority.Use Expected Response:
POST only for newly opened accounts. If the account was opened and closed on the same day, include closedDate in the request - no separate update is required.Request: POST /reports/sask/v1/accountsRequest Body:The
representatives array is optional. Include it when the account has authorized representatives.Store the returned
refId for use in Test Cases 2, 3, and 4.Test Case 2: Update Account
Test Case 2: Update Account
Objective: Update a previously reported account when account details or owner information changes.The Expected Response:
refId from the original account submission is required to identify the record to update.Request: PUT /reports/sask/v1/accountsRequest Body:Test Case 3: Create Representative
Test Case 3: Create Representative
Objective: Add a new representative for an already reported account.The Expected Response:
accountRefId in the URL must be the refId returned when the account was reported.Request: POST /reports/sask/v1/accounts/{accountRefId}/representativesRequest Body:Store the returned representative
refId for Test Case 4.Test Case 4: Update Representative
Test Case 4: Update Representative
Objective: Update a representative when their information changes, or end the representative relationship by adding Expected Response:
dateTo.Request: PUT /reports/sask/v1/accounts/{accountRefId}/representativesRequest Body:Batch Submission Tests
Test Case: Batch Submission - All Success (HTTP 200/201)
Test Case: Batch Submission - All Success (HTTP 200/201)
Objective: Verify batch submission where all records are valid.Steps:
- Submit multiple valid records in a single request
- Verify HTTP 200 or 201 response
- Confirm all items have
status: SUCCESS
Test Case: Batch Submission - Partial Success (HTTP 207)
Test Case: Batch Submission - Partial Success (HTTP 207)
Objective: Verify batch submission where some records fail validation.Steps:
- Submit multiple records where at least one has invalid data
- Verify HTTP 207 response
- Confirm successful items have
status: SUCCESS - Confirm failed items have
status: FAILEDwith error details
Test Case: Batch Submission - All Failed (HTTP 400)
Test Case: Batch Submission - All Failed (HTTP 400)
Objective: Verify batch submission where all records fail validation.Steps:
- Submit multiple records where all have invalid data
- Verify HTTP 400 response
- Confirm all items have
status: FAILEDwith error details
Best Practices
Store Reference IDs
Always save the
refId returned for each created record. You need this ID to update or delete records later.Handle Partial Success
When you receive HTTP 207, check each item in the response array. Some items succeeded while others failed.
Validate Before Submission
Validate your data locally before sending to reduce failed submissions and improve processing speed.