Skip to main content
POST
Why it’s useful: Use it to pay super for several workers and funds in one request.

Simplified Request Format

Instead of providing the full contribution payload, you only need to provide:
  • Employer ID: The employer ID that this contribution belongs to (required)
  • Fund USI: The superannuation fund identifier
  • Employee ID: Reference to employee stored in database (from GET /v1/employees)
  • Amounts: Contribution amounts for each employee
  • Pay Periods: Start and end dates for the pay period
  • Employment Status: Employment status for this pay period
  • invoiceNumber (optional): An invoice reference you can attach to each fund in the request (funds[].invoiceNumber)

Multi-fund + Multi-member

  • A single request can include multiple funds (contributionDetails.funds[]).
  • Each fund can include multiple members (funds[].members[]).

Payments Created

We create 1 payment history record per member (per fund) in the Submitted History section.

invoiceNumber Attachment

If provided, invoiceNumber is:
  • Sent as funds[].invoiceNumber in this simplified request
  • Stored on each created payment record as payment.invoiceNumber
All created payment records share the same transactionId returned by the upstream clearing service. Each payment record also contains the associated fund info at payment.contributionDetails.fund (e.g. USI), so you can see which fund was associated with that member payment. For this simplified endpoint, you do not send memberNumber or employmentPayrollNumber in the member objects. These identifiers are automatically populated from the onboarded employee record and passed through in the full clearing-house payload that we build internally.

Workflow

  • Onboard Employer: Store employer information in database (internal process)
  • Onboard Employees: Use POST /v1/employees to store employee static data (including USI, memberNumber, and employmentPayrollNumber)
  • Submit Contribution: Use this endpoint with employerId and only variable data

Benefits

  • Reduced Payload Size: Only send variable data that changes per contribution
  • Data Consistency: Static data is stored once and reused
  • Simplified Integration: Less data to manage in your payroll system
  • Automatic Updates: Update employee data once, affects all future contributions

Automatic Contribution History Storage

When contributions are submitted via this endpoint, the system automatically stores the contribution details in the history. This happens in the background and does not affect the contribution submission response. You can retrieve the stored contribution history using the GET /v1/contributions/submitted/history endpoint. Note: This automatic storage ensures all submitted contributions are tracked and can be retrieved later for auditing, reporting, or reconciliation purposes.

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

Example Request

Request Body

string
required
Employer ID that this contribution belongs to. The employer must be associated with the authenticated client.
object
required
Simplified contribution details. Only variable data (fund USIs, amounts, pay periods) is required. Employee and employer static data will be automatically retrieved from the database.

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.
The complete contribution payload that was submitted to Superannuation clearing house API. This includes all employer details, fund information, and member contributions with full employee data.
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