Welcome to the splose API documentation. splose serves as a comprehensive Allied Health & NDIS practice management software designed to streamline administrative tasks and foster the growth of your practice.
The splose API follows a REST architectural style, offering JSON-encoded responses, standard HTTP response codes, easily understandable resource-oriented URLs, and robust authentication mechanisms.
https://api.splose.com/v1
https://api-uk.splose.com/v1
(UK users)The splose API employs API keys for request authentication. Workspace owners can apply for and manage API keys through the splose dashboard. It’s crucial to safeguard the API key, as it grants the same permissions as the associated user.
Authentication for API access is achieved via Bearer Authentication. Include the API key in the request header using the format: Authorization: Bearer your_api_key
.
All API requests must be conducted over HTTPS. Requests made over plain HTTP will not succeed. Additionally, unauthenticated API requests will result in failure.
There are limits to the number of API calls that your application can make with one API key.
splose uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx range indicate success.
Codes in the 4xx range indicate an error that failed given the information provided. Codes in the 5xx range indicate an error with splose’s servers.
Error types:
400 - Bad request: the request failed due to missing or invalid parameters.
401 - Unauthorized: No valid API key provided.
404 - Not Found: The requested resource doesn’t exist.
429 - Too Many Requests: Too many requests hit the API too quickly.
500 - Internal Server Error : Something went wrong on splose’s end.
All datetime values provided in request parameters and responses are in Coordinated Universal Time (UTC). The accepted datetime formats are outlined below:
2023-07-01
2023-07-01T00:00:00Z
2023-07-01T00:00:00.000Z
For endpoints returning multiple objects, pagination is in place to manage response sizes. Each response is limited to a certain number of objects.
Additionally, the response includes a links
field that provides URLs for fetching the next and/or previous pages, if applicable.
You have the option to manually specify the id_gt
or id_lt
value as a request parameter. This allows you to retrieve objects starting from a specific position. If neither of these values is provided, the initial page of objects will be returned by default.
id_gt
: Request for next page of objects with id greater than the specified value.
id_lt
: Request for previous page of objects with id less than the specified value.
Certain users may require real-time data retrieval. Given the substantial data volume, retrieving the complete dataset may not be efficient. To address this, we offer the option to retrieve data based on its update timestamp. This approach necessitates fetching the entire dataset only during the initial request. Subsequent retrievals involve fetching solely the modified data to replace outdated information.
update_gt
: Request for objects updated after the specified datetime.
update_lt
: Request for objects updated before the specified datetime.
2025-06-20
credit-note
endpoint2025-05-12
caseId
into appointmentPatient
field for appointment
response2025-03-13:
custom-filed
endpointpatient
patient
2025-02-14:
contact
email
field to practitioner response2025-01-31:
patient
appoitment
2024-12-13:
patient
to upload file for patient2024-11-27:
name
to contact response.2024-11-22:
cancellationRate
to appointment response.2024-09-30:
contact
endpoint.invoiceRecipientId
to patient response.2024-09-03:
appointment
and support-item
endpoints.status_update_lt
and status_update_gt
parameter to appointment
endpoint.2024-06-25:
case
, patient-form
, screener
and waitlist
endpoints.customFields
to patient response.statusUpdatedAt
to appointment response.2024-04-29: add payment-method
and payment
endpoints.
2024-02-28: add availability
endpoint.
Welcome to the splose API documentation. splose serves as a comprehensive Allied Health & NDIS practice management software designed to streamline administrative tasks and foster the growth of your practice.
The splose API follows a REST architectural style, offering JSON-encoded responses, standard HTTP response codes, easily understandable resource-oriented URLs, and robust authentication mechanisms.
https://api.splose.com/v1
https://api-uk.splose.com/v1
(UK users)The splose API employs API keys for request authentication. Workspace owners can apply for and manage API keys through the splose dashboard. It’s crucial to safeguard the API key, as it grants the same permissions as the associated user.
Authentication for API access is achieved via Bearer Authentication. Include the API key in the request header using the format: Authorization: Bearer your_api_key
.
All API requests must be conducted over HTTPS. Requests made over plain HTTP will not succeed. Additionally, unauthenticated API requests will result in failure.
There are limits to the number of API calls that your application can make with one API key.
splose uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx range indicate success.
Codes in the 4xx range indicate an error that failed given the information provided. Codes in the 5xx range indicate an error with splose’s servers.
Error types:
400 - Bad request: the request failed due to missing or invalid parameters.
401 - Unauthorized: No valid API key provided.
404 - Not Found: The requested resource doesn’t exist.
429 - Too Many Requests: Too many requests hit the API too quickly.
500 - Internal Server Error : Something went wrong on splose’s end.
All datetime values provided in request parameters and responses are in Coordinated Universal Time (UTC). The accepted datetime formats are outlined below:
2023-07-01
2023-07-01T00:00:00Z
2023-07-01T00:00:00.000Z
For endpoints returning multiple objects, pagination is in place to manage response sizes. Each response is limited to a certain number of objects.
Additionally, the response includes a links
field that provides URLs for fetching the next and/or previous pages, if applicable.
You have the option to manually specify the id_gt
or id_lt
value as a request parameter. This allows you to retrieve objects starting from a specific position. If neither of these values is provided, the initial page of objects will be returned by default.
id_gt
: Request for next page of objects with id greater than the specified value.
id_lt
: Request for previous page of objects with id less than the specified value.
Certain users may require real-time data retrieval. Given the substantial data volume, retrieving the complete dataset may not be efficient. To address this, we offer the option to retrieve data based on its update timestamp. This approach necessitates fetching the entire dataset only during the initial request. Subsequent retrievals involve fetching solely the modified data to replace outdated information.
update_gt
: Request for objects updated after the specified datetime.
update_lt
: Request for objects updated before the specified datetime.
2025-06-20
credit-note
endpoint2025-05-12
caseId
into appointmentPatient
field for appointment
response2025-03-13:
custom-filed
endpointpatient
patient
2025-02-14:
contact
email
field to practitioner response2025-01-31:
patient
appoitment
2024-12-13:
patient
to upload file for patient2024-11-27:
name
to contact response.2024-11-22:
cancellationRate
to appointment response.2024-09-30:
contact
endpoint.invoiceRecipientId
to patient response.2024-09-03:
appointment
and support-item
endpoints.status_update_lt
and status_update_gt
parameter to appointment
endpoint.2024-06-25:
case
, patient-form
, screener
and waitlist
endpoints.customFields
to patient response.statusUpdatedAt
to appointment response.2024-04-29: add payment-method
and payment
endpoints.
2024-02-28: add availability
endpoint.