Skip to main content
POST
Why it’s useful: Use it to check the USIs your workers have already entered, so you know each fund can receive contributions.

Simplified Request Format

The fund validation endpoint has been simplified to automatically retrieve employer information from the database. You only need to provide the fund USIs you want to validate. Minimal Request (Recommended):
The system automatically retrieves your employer information based on your authentication credentials, so you no longer need to include employer details in the request.

Transaction ID - Server-Generated

The server automatically generates a unique transaction ID and timestamp for each request. Transaction ID Format: txn-{uuid} Example generated IDs:
  • txn-550e8400-e29b-41d4-a716-446655440000
  • txn-6ba7b810-9dad-11d1-80b4-00c04fd430c8
The transaction ID will be:
  • Included in all response payloads
  • Available in error messages for troubleshooting
  • Returned in response headers for request tracking

Transaction ID in Response

The validate fund endpoint returns the server-generated transaction ID in the response:
Use this ID for logging, debugging, and tracking requests in your system.

Validation Checks Performed

  • USI Format: Verifies the USI follows the correct 14-character format
  • Fund Active Status: Confirms the fund is currently accepting contributions
  • Electronic Capability: Verifies the fund can receive SuperStream contributions
  • Employer Association: Optional check if employer is already registered with the fund

When to Use

  • Member Onboarding: Validate the fund USI provided by a new employee
  • Choice of Fund: Verify funds before presenting them to employees
  • Pre-submission Check: Validate all funds in a batch before submission
  • Periodic Verification: Funds occasionally change status (mergers, closures)

Common USI Issues

  • Fund has merged with another fund (will return new USI)
  • Fund is temporarily not accepting electronic contributions
  • USI is for a closed or legacy product

Benefits of Simplified Format

  • Simpler Integration: No need to manage employer details
  • Smaller Request Payloads: Only send what’s necessary
  • Always Up-to-Date: Uses the most current employer information from the database
  • Consistent Data: Same employer data used across all requests

Best Practices

  • Cache valid USIs for up to 24 hours
  • Always re-validate before first contribution to a new fund
  • Handle fund merge redirects gracefully
  • Use the transaction ID from responses for request tracking

Request Body

array
required
Array of superannuation fund USIs (Unique Superannuation Identifiers) to validate. Each USI will be checked against the active funds registry to ensure it can accept contributions.

Responses

Response fields

boolean
Indicates whether the operation completed successfully. True means the validation passed or submission was accepted.
integer
HTTP status code of the response. 200 indicates success.
string
Human-readable message describing the operation result. For successful operations, provides confirmation of what was validated or submitted.
string
Server-generated transaction ID in the format txn-{uuid}. This ID is automatically generated by the server for tracking and correlation purposes. Use this ID for logging, debugging, and tracking requests in your system.
boolean
Always false for error responses, indicating the operation did not succeed.
integer
HTTP status code indicating the type of error. Common values: 400 (Bad Request), 401 (Unauthorized), 404 (Not Found), 500 (Server Error)
string
Human-readable error message explaining what went wrong. May include specific details about which field or value caused the error.
integer
Superannuation clearing house-specific error code for programmatic error handling. Refer to the error code reference documentation for a complete list of codes. Common codes: 4030 (Employer not found), 4031 (Invalid ABN), 4040 (Fund not found).
Last modified on November 10, 2026