Test your configuration

MyGigsters provides a pre-configured Postman collection that tests your Super integration. It has 18 go-live checks that you must pass before moving to production, plus 24 further scenarios, and it checks each response for you.

Run the suite against the demo (QA) environment with your demo API key. Don’t run it against production: it creates employers and employees and submits contributions.

What you need

Postman, desktop or web.
A demo API key. See Authentication.
An employer that has finished onboarding at the clearing house. You receive the employer.onboarded_at_clearing_house webhook when it’s ready.

Test using Postman

Import the collection and environment

In Postman, select Import and paste each link.

File	Link
Collection	`https://raw.githubusercontent.com/mygigsters/Mintlify-Documentation-Swami/main/postman/mygigsters-super-qualifying-tests.postman_collection.json`
Environment	`https://raw.githubusercontent.com/mygigsters/Mintlify-Documentation-Swami/main/postman/mygigsters-super-qa.postman_environment.json`

Fill in the environment

Select the MyGigsters Super QA environment and set the variables below.

Run the collection

Open the collection, select Run, keep the folders in their original order, and select Run MyGigsters Super: qualifying tests. By default only the 18 go-live checks run and the rest are skipped. Each scenario saves the IDs the next one needs, so run the whole collection in order.

Review the results

Every scenario shows as passed or failed with its ID, for example CON-04. Select a failed scenario to see the request and response.

Environment variables

Variable	Required	What to enter
`baseUrl`	Yes	`https://qa-super.mygigsters.com.au`. Already set.
`suite`	Yes	`go-live` runs only the go-live checks. `all` runs every scenario. Set to `go-live` by default. Skipping needs a recent version of Postman; older versions run every scenario.
`apiUsername`	Yes	Your demo `apiUsername`.
`apiPassword`	Yes	Your demo `apiPassword`.
`existingEmployerId`	Recommended	The ID of an employer that has finished onboarding at the clearing house. Used for verification and contributions. If blank, the suite uses the employer it creates in EMPR-01, which may not be ready yet.
`fundUsi`	Optional	The USI to test with. If blank, the suite uses the first fund returned by FND-01.
`employerAbn`	Yes	A valid ABN for the test employer created in EMPR-01. Replace the default with your own if it’s rejected as already in use.
`smsfAbn`	Optional	The ABN of the SMSF used in the SMSF scenarios.
`webhookUrl`	Optional	The HTTPS endpoint to register in WHK-01.

The suite generates a unique email, tax file number, member number, and payroll number for each employee it creates, so you can run it as often as you like.

Test scenarios

The scenarios are grouped by capability, in the order the collection runs them.

Marker	Meaning
★	Go-live check. Must pass before you move to production. There are 18.
No marker	Further scenario. Recommended, and useful when a go-live check fails. Run with `suite` set to `all`.

In Postman, go-live checks have the same ★ at the start of their name.

Authentication

Confirms your API key works and that bad credentials are refused. See authentication.

	ID	Scenario	Request	Expected result
★	AUTH-01	Valid API key is accepted	`GET /v1/employees`	`200`. Returns your employee list.
★	AUTH-02	Invalid API key is rejected	`GET /v1/employees`	`401`. Request is refused.

Funds

Confirms you can list funds, validate a USI, and look up a worker’s existing fund. See funds.

	ID	Scenario	Request	Expected result
★	FND-01	List active funds	`GET /v1/contributions/funds/active`	`200`. Returns a non-empty `funds` array.
★	FND-02	Validate an active fund	`POST /v1/contributions/fund/validate`	`200`. `success` is `true` and a `transactionId` is returned.
	FND-03	Reject an invalid USI	`POST /v1/contributions/fund/validate`	`400`. Validation fails.
	FND-04	Find a fund with SuperSelector	`POST /v1/verification/superselector`	`200`. `matchResult` is `MATCH` or `NO_MATCH`.

Employers

Confirms you can onboard an employer and that invalid details are rejected. See employers.

EMPR-01 creates a new employer on every run. A new employer isn’t ready for contributions until it finishes onboarding at the clearing house, so set existingEmployerId for the later folders.

	ID	Scenario	Request	Expected result
★	EMPR-01	Onboard an employer	`POST /v1/employers/onboard`	`201`. Returns an `employerId`.
	EMPR-02	Reject a duplicate contact email	`POST /v1/employers/onboard`	`400`. Error code `4003`.
	EMPR-03	Reject an ABN that fails the checksum	`POST /v1/employers/onboard`	`400`. Employer is not created.
★	EMPR-04	Get the employer by ID	`GET /v1/employers/{employerId}`	`200`. Returns the employer you created.
	EMPR-05	List your employers	`GET /v1/clients/me/employers`	`200`. The list includes the new employer.
	EMPR-06	Unknown employer returns not found	`GET /v1/employers/000000000000000000000000`	`404`. Employer not found.

Employees

Confirms you can create, find, and update the workers you pay super for. See employees.

	ID	Scenario	Request	Expected result
★	EMPE-01	Create an employee	`POST /v1/employees`	`201`. Returns an `employeeId`.
★	EMPE-02	Reject a duplicate email	`POST /v1/employees`	`400`. Employee is not created.
★	EMPE-03	Get the employee by ID	`GET /v1/employees/{employeeId}`	`200`. Returns the employee you created.
	EMPE-04	Search employees by email	`GET /v1/employees/search`	`200`. Results include the new employee.
	EMPE-05	Update the employee	`PUT /v1/employees/{employeeId}`	`200`. Payroll number is updated.
	EMPE-06	Unknown employee returns not found	`GET /v1/employees/000000000000000000000000`	`404`. Employee not found.
	EMPE-07	Get super owed for the employee	`GET /v1/employees/{employeeId}/super-owed`	`200`. Returns a `total` amount.

Member verification

Confirms you can verify a member with their fund before you pay. See member verification.

MVR-02 and MVR-03 need an employer that has finished onboarding at the clearing house. If the fund doesn’t support verification yet, MVR-03 returns 400 with error code 4032. Set fundUsi to a fund that supports it.

	ID	Scenario	Request	Expected result
★	MVR-01	Create an employee with verification (v2)	`POST /v2/employees`	`201`. Response includes `mvrStatus`.
	MVR-02	Validate a verification request	`POST /v2/mvr/validate`	`200`. `success` is `true`.
★	MVR-03	Submit a verification request	`POST /v2/mvr/submit`	`200`. Returns a `transactionId`.
★	MVR-04	Get the verification outcome	`GET /v2/mvr/{transactionId}`	`200`. `status` is a valid verification status.
	MVR-05	Unknown verification returns not found	`GET /v2/mvr/txn-00000000-0000-0000-0000-000000000000`	`404`. Verification not found.
	MVR-06	Force a verified status (testing only)	`PATCH /v2/mvr/employee/{employeeId}`	`200`. Status is set to `VERIFIED`.
	MVR-07	Employee shows the verified status	`GET /v1/employees/{employeeId}`	`200`. `mvrStatus` is `VERIFIED`.

Contributions

Confirms you can submit contributions, both directly and asynchronously, and that retries are safe. See contributions.

These scenarios submit contributions of A$1.00 for the employee created in EMPE-01.

	ID	Scenario	Request	Expected result
★	CON-01	Submit a contribution	`POST /v1/contributions/contribution`	`200`. Returns a `transactionId`.
	CON-02	Reject a contribution for an unknown employee	`POST /v1/contributions/contribution`	`400` or `404`. Nothing is submitted.
★	CON-03	Submit a contribution asynchronously	`POST /v2/contributions`	`202`. `status` is `ACCEPTED` and a `transactionId` is returned.
★	CON-04	Retry with the same idempotency key	`POST /v2/contributions`	`202`. Returns the original `transactionId`. Nothing is submitted twice.
	CON-05	Reuse the key with a different body	`POST /v2/contributions`	`409`. Conflict.
	CON-06	Missing idempotency key	`POST /v2/contributions`	`400`. Request is rejected.
★	CON-07	Get the async submission status	`GET /v2/contributions/{transactionId}`	`200`. `status` is a valid submission status.
	CON-08	Get contribution history	`GET /v1/contributions/submitted/history`	`200`. Returns a `contributions` array.

Payment status

Confirms you can track a contribution after you submit it. See payment status.

	ID	Scenario	Request	Expected result
★	PAY-01	Get the payment status of a contribution	`GET /v1/payments/paymentstatus/transaction/{transactionId}`	`200`. Returns the payment overview.
	PAY-02	Unknown transaction returns not found	`GET /v1/payments/paymentstatus/transaction/txn-00000000-0000-0000-0000-000000000000`	`400` or `404`. Transaction not found.

Self-managed super funds

Confirms you can pay contributions to a self-managed super fund. See self-managed super funds.

ID	Scenario	Request	Expected result
SMSF-01	Create an employee with an SMSF	`POST /v1/employees`	`201`. Returns an `employeeId`.
SMSF-02	Reject an employee with both a USI and an SMSF	`POST /v1/employees`	`400`. Employee is not created.
SMSF-03	Submit a contribution to an SMSF	`POST /v1/contributions/contribution`	`200`. Returns a `transactionId`.

Webhooks

Confirms you can register the endpoint that receives events. See webhooks.

Registering a webhook replaces your current demo webhook URL and rotates its secret. Set webhookUrl to an endpoint you control, or skip this folder.

	ID	Scenario	Request	Expected result
★	WHK-01	Register a webhook	`POST /v1/webhooks`	`200` or `201`. Returns a `webhookSecret`.
	WHK-02	Reject an invalid webhook URL	`POST /v1/webhooks`	`400`. Webhook is not changed.

Embedded components

Confirms your backend can create the short-lived token the embedded components need. See embedded components.

	ID	Scenario	Request	Expected result
	CMP-01	Create a component session	`POST /widget/session`	`200`. Returns a `token` that expires in 600 seconds.

Move to production

Your integration is ready for production when all 18 go-live checks pass in the demo environment.

Export your results

In the Postman runner, select Export Results.

Send them to us

Email the file to hello@mygigsters.com.au with your client name. If a check fails for a reason you expect, for example a fund that doesn’t support verification yet, say so in your email.

Switch to production

Once we confirm, create a production API key and change your base URL to https://super.mygigsters.com.au. See Authentication.

Onboard your real employer

Employers, employees, and webhooks from the demo environment don’t carry over. Onboard them again in production before you submit your first contribution.

Don’t run this suite in production. It creates test records and submits contributions.

Not covered yet

These need manual steps or specific timing, so they aren’t in the suite. They’ll be added as the suite grows.

Capability	Why it’s not in the suite
Creating an API key	Needs a one-time passcode sent by email. See Authentication.
Bulk upload of employees	Needs a CSV file attached to the request.
Cancelling a contribution batch	Only works while the debit is initiated but not yet cleared.
Verification outcomes from a fund	A fund can take 24 to 48 hours to respond. MVR-06 forces a status instead.
Payment status changes over time	Payments move through their stages over several days.
Webhook deliveries	Needs a public endpoint that records what it receives.
Embedded component screens	The onboarding forms and dashboard are tested in a browser, not through the API.

Get help

Email hello@mygigsters.com.au with the scenario ID, the transactionId from the response if there is one, and the time you ran the test.

Get started

Guides

What you need

Test using Postman

Environment variables

Test scenarios

Authentication

Funds

Employers

Employees

Member verification

Contributions

Payment status

Self-managed super funds

Webhooks

Embedded components

Move to production

Not covered yet

Get help

​What you need

​Test using Postman

​Environment variables

​Test scenarios

​Authentication

​Funds

​Employers

​Employees

​Member verification

​Contributions

​Payment status

​Self-managed super funds

​Webhooks

​Embedded components

​Move to production

​Not covered yet

​Get help

What you need

Test using Postman

Environment variables

Test scenarios

Authentication

Funds

Employers

Employees

Member verification

Contributions

Payment status

Self-managed super funds

Webhooks

Embedded components

Move to production

Not covered yet

Get help