TASS's New API Program Webinar 2026 Video Q&A

Will the existing API remain so our school’s API integrations continue working?

Nothing will break with existing connections; the current RESTful API library hosted on GitHub will not be retired yet.

Will you be updating the Github documentation? 

Documentation for the existing API will continue to be available in GitHub. Documentation for the new API will be hosted on the public website at api.developer.tassweb.com.au.

What kind of functionality does the new API program have?

Nearly every API endpoint has Get, Post, Put, Patch and Delete functionality. 

When will the new API program become available?

Within the next one to two months. If it doesn't come out in a General Release, then it may come out as a patch as soon as it's available. Keep your email subscription up-to-date to ensure you receive any Software Notifications.

How can our school update to the new API program sooner if our school is ready?

The system is currently behind a Feature Flag. Please reach out to your Customer Success Consultant if you are interested. 

Do we need to reach out to existing external partners to migrate, or will it get done by TASS' Support Team?

Given each school's unique situations and configurations, it is best for schools to directly liaise with their external partners for migration. 

What kind of pricing changes can my school expect with this new API program? 

All APIs, whether your school is using the existing or new program, are now be included within your TASS License fee. SMS will remain chargeable. 

Will there be any logs for the API Calls?

Yes, there is an API log already in place in the database. Every API call gets logged, not just errors, with details about each call.  We will be working to expose a UI for viewing logs and statistics within the next couple of months.

Will there be a Postman collection published in tandem with the API documentation site?

Not at this stage. We can have a look at this further to see if we can create a collection outside of that space.

Do the old APIs include things like the address validation? Are there plans to port that one over to the new API program?

No. This is an external API that performs a function within the TASS software.

Are we going to be able to call multiple companies at the same time? 

Not yet, but it's something we're exploring.

Will there be any option to restrict API calls by whitelisting IP addresses?

There are no plans for implementing whitelisting within the API itself. The security system in place is quite robust. If whitelisting is an extra option that a school wants to place for added security, then that can easily be achieved by a school's IT team or TASS technical services placing IP restrictions in IIS against the API website.

What is the release process for certain fields being exposed in different calls?

Identifying something that's missing, or you wanting added is best submitted via a Software Support ticket, like a feature request. If a certain field isn't coming through, we can have a look at whether it is conditionally generated.

How does the API perform for large enterprise schools who have a large number of records?

Performance will be greater with the new API system.  In the old system, there was no pagination before, which is why that crashed in certain circumstances. The new API program has pagination built-in at 500 records.

Does OData optimise the queries to the database?

Yes. We're using a combination of Entity Framework and handcrafted SQL (for more complex scenarios) for the back end on how it interacts with the database. Both options will cater for Odata filters, sorting, paging etc. so as to improve performance and minimse impact on SQL.

Will the "shape" of endpoints change from the old API system to the new?

Yes. They are proper JSON response objects.  "Lists" are no longer literal comma separated values; they're proper arrays of values. If using Python, the JSON responses convert nicely to data types, like lists.

Is throttling implemented if multiple requests need to run concurrently?

Yes, rate limiting has been implemented in the new API to stop spamming of endpoints (mostly a security feature in case somebody is trying a brute force attack). The user login endpoint has a limit of 10 calls per minute from the same user and/or IP address and all other endpoints have a limit of 200 calls per minute from the same user and/or IP address.

Does this have any impact of APIs with partner systems?

We will do a full review of our integration partners, including what they're using, how much they're using it, and prioritise them to migrate onto the new system. 

How will error handling be documented? 

There's usually a JSON error response that contains error messages about why things fail. The API documentation has response codes and the JSON object that it returns (if applicable) that relates to that response code.