PPSR API
The Personal Property Securities Register (PPSR) is a centralised, electronic register where details of security interests in personal property can be registered and searched. The PPSR API provides a real-time, secure, direct link between your business systems and the PPSR. You can conduct most PPSR transactions, including searches, registrations, renewals, amendments and discharges, directly from your own software, instead of using the PPSR website.
If you carry out a large number of PPSR transactions you should consider using this API with either an off the shelf product from a third-party software provider, or your own custom integration with the API. This can streamline your business processes and save you money as PPSR transaction fees are lower via the API channel compared to the website.
Using the API
Follow these steps to get up and running:
Read the technical details
View the API definition in our developer portal here. You can also download the definition for viewing in Swagger Editor, SwaggerHub, or other tools.
Set up a user in the PPSR system
To use the API you first need to have created a PPSR organisation account, and will also need an approved direct debit authority before you can use any fee-bearing API operations (search, registration, renewal) in production.
There are separate websites for PPSR sandbox and PPSR production environments. If you will use the API for test and production purposes then you will need to log in and create a PPSR organisation account in each environment.
The PPSR Sandbox WebUI User Guide contains details on how to get started setting up in sandbox, including creation of a dummy direct debit payment authority. It can be used for reference setting up in production too.
For the sandbox environment, please contact us to complete the set up once you have submitted the dummy direct debit authority request.
Subscribe to the API
Log in and subscribe to the PPSR API Product. Our API support team may request further information before the subscription can be approved.
Generate an API subscription key
For full details on how to generate an API subscription key please see here.
Once your subscription has been approved you will be able use your API credentials to successfully call the API. Use the sandbox key and sandbox endpoints in your software development. Once you've completed testing simply use your production keys to access the live service.
Optionally generate an OAuth2 token for user authorisation
The preferred method for software products to access the PPSR API is with a three-legged OAuth token that is associated with a PPSR user. A description of the options for PPSR user and organisation set up is provided in the PPSR API Authentication Options & User Scenarios document.
The three-legged OAuth method is suited to software products that have multiple end users with different PPSR accounts. The software provider will need an approved API subscription, but none of the end users of the software need to subscribe to the API.
Consent is provided by the end user logging in with the RealMe account that they use on the PPSR website. The 3-legged token that is generated in this process can then be used in future requests to the API.
Technical details of how to generate this token are available here.
API reference material
Validation and business rules
Refer to the PPSR API Business Rules document for details of conditional rules for usage of the API operations.
The following validation rules / behaviour are applied:
Date and time formats
Format for all operations other than PPSR_43 GET /customer-organisation-fees
Format for PPSR_43 GET /customer-organisation-fees
Rate limiting
Rate limiting is applied to PPSR resources to limit the rate of requests per user per minute that can be processed.
Timeouts and retries
The MBIE API platform applies a 180 second timeout to all PPSR API operations to prevent any long running processes from saturating available API threads on our platform. All transactions are expected to be completed well within that timeframe, but in exceptional circumstances it is possible that the API may timeout, while the operation may still successfully complete on the register after this period.
To minimise the risk of sending duplicate transactions we recommend the following:
Set your software timeout to be greater than 180 seconds. This will reduce the risk of your application timing out, when the MBIE API platform or register may successfully complete.
Use a "back off" period when it is necessary to retry a transaction.
Test the status of timed-out transactions using PPSR_56 GET /customer-organisation-transactions and supplying either request-id or billing-reference. Note that a transaction will not be returned by PPSR_56 response while it is still being processed, only after it has completed or resulted in an error. Use transaction.statusCode in the PPSR_56 response to determine the next steps:
