The Houski API is engineered to help you hit the ground running. From the moment you access our API, you'll find intuitive endpoints, clear documentation, and example requests that can be executed right away. We've minimized the number of steps required to make your first successful API call. This quick start design minimizes setup time, allowing you to integrate the Houski API into your application or service with minimal friction.
You're billed only for the data/fields you actually request. Whether it's a simple address field or more complex data sets like a property's assessment history, you're in control of your costs. You can customize your queries to include only the data you need, making the API both flexible and cost-effective.
The Houski API offers a standardized way to sort, filter, and select data fields across all endpoints. Whether you're filtering properties by geographical boundaries or querying specific attributes, the API uses consistent query parameters. This uniformity simplifies the learning curve, allows for easier code reusability, and enhances the developer experience.
By appending ?price_quote=true to your query, you can instantly get a cost estimate for that specific request. This allows you to gauge the expense before executing the query and obtaining the data.
Each endpoint returns data in a uniform structure or 'type.' This ensures a predictable experience when you're coding in strongly-typed languages. Even when an error occurs, the response will still conform to the expected type, making it easier to handle in your application.
We've designed the API to negate the need for retrieving results by ID, although the API does provide IDs. This design philosophy was implemented mainly for SEO reasons, and to provide an opinonated structure that makes designing front end interfaces that navigate Houski's property data API both simple and intuitive.
Retrieving property results is typically done through a hierarchy of string-based information. This may sound strange, but it's quite simple.
Consider the structure of this URL:
https://houski.ca/property/ca/ab/calgaryWe can derive quite a bit of data from the structure of that URL, such as the country (abbreviation), the province (abbreviation), and the city. This is already enough information for the Houski API to retrieve all of the properties in that area.
A request to the Houski API doesn't need to know the ID of the city, province, etc, because long story short, this string based location hierarchy is always deterministic. The IDs of the property, city, province, etc, are all derived by the Houski API automatically.
To optimize the API for use cases involving user interfaces, responses contain links to where the other resources should on a front-end interface. For example, if you request properties from the /properties endpoint, each property returned also contains a relative link in the response to the URL that can retrieve that property's details. Note, you must select the links you want as fields in your request.
The UI_info object contains relevant context for the query's results. For example, it contains the community, city, address, and province and country information, even if the request returns no actual results. This creates a stable resource for the UI, which facilitates the creation of things like navigation breadcrumbs - even on pages where no property is found that matches the criteria of the request.
Where applicable, API requests return a standard pagination object. This object contains relevant information for paginating results. This object is stable between relevant endpoints, so any required pagination logic can easily be re-used.