The RLP API allows case management systems to import details of an application to update the Land Register into RLP, reducing duplicate data entry.
The API supports importing core case details plus deed parties for dispositions, standard securities and discharges of standard security over the whole of a single title. Advance notices, Land Register application forms and digital discharges can then be submitted by logging in to Online Services and completing additional details.
The following summary shows how an RLP case will typically be created and submitted when using the API to import the details.
The user enters details of the case into their CMS
The user confirms the case details are ready to import
The CMS imports core case details using the Create Case endpoint
Matter reference
Title number
FAS number
User's contact details
The CMS adds deeds using the Add Deed endpoint
Deed type
Notification email addresses (optional)
Applicant names and addresses (optional)
Granter names and addresses (optional)
The CMS displays a link to the case in the RLP UI
The user opens the RLP UI, reviews the imported details and submits advance notices
At a later date the user returns to the RLP UI, completes additional details for the applications and submits them
Notes:
Data listed as optional above may be omitted from API calls and added later using the RLP UI.
Cases created via the API are visible and searchable in the RLP organisation dashboard in the same way as any other case.
There are restrictions on the parties that can be included depending on the deed type. These are documented in the next section.
Deed-specific rules
RLP simplifies the submission of the most common deeds and helps Registers of Scotland register them more accurately and efficiently by requiring the selection of the correct standard security to discharge when submitting a discharge deed, and selection of the lender when submitting a standard security deed, whenever this is possible.
We have designed the API to preserve these benefits of RLP for users and for RoS, therefore there are limitations on what deed parties can be populated via the API, and special rules when creating a discharge.
Deed parties are optional. Integrations do not need to add deeds to cases, or can add deeds without adding the parties, and the user will need to complete remaining details in the UI. However, when a party is added via the API it must be complete, with a valid name and address.
Disposition parties, Show this section
When creating a disposition, both granters and applicants can be populated via the API.
It is not currently possible to complete an Overseas Entity declaration under the terms of the Economic Crime (Transparency and Enforcement) Act 2022 via the API. If a party is not an individual or a UK company, the user must answer the Overseas Entity questions in the UI.
Standard security parties, Show this section
The granters of a standard security can be populated via the API. As for dispositions, the Overseas Entity declaration must be completed in the UI if relevant.
The applicant for a standard security is typically a mortgage lender. The API will only accept a single applicant party identified by a creditor code.
Creditor codes are proprietary to RoS. We maintain a database of codes for active lenders, and provide the Creditor Search endpoint which accepts a simple search string (typically the lender name) and returns matching lenders. Integrations can display matches, ask the user to select the lender designation that exactly matches the deed, and send the corresponding creditor code to the Add Deed endpoint.
It is essential that the user selects the designation that exactly matches the deed for the standard security to be correctly registered. Minor differences in punctuation, character case and order of information can be ignored.
API integrations may choose to omit the applicant party entirely, so the details can be completed in the UI. This is required when there is more than one applicant or the lender is not in our database.
Discharge parties, Show this section
For digital discharges, the granter (lender) details must be populated with the information held by RoS. For paper discharges, the lender details can usually be populated automatically but the user is permitted to correct them. To avoid the confusion of granter details sent via the API being discarded if the discharge will be digital, the API does not accept any granter details for discharge deeds.
Applicant (borrower) details can be provided as normal. This is optional; if details are not provided, RLP will attempt to populate the applicants from the details of the security. Pre-populated applicants can be amended in the UI.
Users are responsible for reviewing the details in the UI before submitting any deed.
Discharge security selection, Show this section
RLP requires the ID of an existing registered security on a title when submitting a discharge deed. This determines whether the discharge will be digital (submitted to the lender for digital signing) or paper (a signed deed submitted by the solicitor).
Integrations can add discharge deeds to a case without specifying a security ID. The user will then be asked to select the correct security when they view the case in the UI.
Alternatively, integrations may query the Title Information endpoint for a list of securities, ask the user to select the correct one, and include the ID in the deed details.
If the title is currently in draft status, there are no registered securities so the security ID cannot be provided. Users must complete the granter details using the UI.
Discharge mortgage numbers, Show this section
When a security can be discharged digitally, RLP allows mortgage numbers to be added to enable the lender to locate the relevant mortgage when they sign the deed. This field is not relevant to paper discharges.
Mortgage numbers can be supplied via the API, but they will not appear in the UI if the security cannot be digitally discharged.
Limitations
Deeds over part, development plan approval (DPA) applications, and other deed and application types cannot be created using the RLP API at this time. Our existing Online Services should be used as normal.
Cases created with the RLP API cannot be made private because they are not associated with an individual user.
Case and deed details cannot be updated via the API. Corrections should be made via the RLP UI.
Authentication
This API uses the industry standard OAuth 2.0 client credentials flow for authentication. A token must be provided with all endpoint calls.
Each API client is linked to an organisation and cases created using a client's API token will belong to that organisation. Cases are not associated with an individual user within the organisation.
All endpoints are free to call. Charges are only incurred when advance notices and applications are submitted using the RLP UI.
Request limits
Each organisation is permitted 1,000 API calls per endpoint per calendar day. Further requests will receive a 429 response.
Pre-requisites
A Registers of Scotland business services account with a pre-payment (registration) FAS account enabled for Direct Debit is required to use this API.
Independent developers building API integrations can apply for a sandbox account. This is free and does not require a Direct Debit agreement.
Character set validation
The validation rules for each field are documented in the OpenAPI specification. In addition to these rules, every input string must use the ISO-8859-1 character set and cannot include any control characters, including new line and carriage return. Users of your integration should be asked to modify any input containing these characters to avoid validation errors. Strings may be validated with the regular expression below.
^[\u0020-\u007E|\u00A1-\u00AC|\u00AE-\u00FF]*$
Sandbox environment
To support development of API integrations a sandbox environment is available. The RLP API in this environment works exactly like production, except that there is a small selection of anonymised titles available, instead of the whole Land Register.
There is an RLP UI in the sandbox environment. This allows developers to review the cases they have created via the API and confirm their integration is working correctly. All the functionality of creating cases and adding deeds is available, but advance notices, digital discharges and application forms cannot be submitted.