In addition to the instructions shown here, you will need to follow the [Liquid Planner API Guide](http://www.liquidplanner.com/assets/api/liquidplanner_API.pdf) and the [Types Documentation](https://app.liquidplanner.com/api/help/types) to see which fields are available.

With the exception of `account` and `workspaces`, all other entities require a workspace to be specified. When instantiated, the API requests a list of available workspaces and defaults to the first returned. You can disable this check by passing the `use_first_workspace` argument.

This library wraps the objects returned in a `dict` like object. This is done so that relateditems can be accessed via the objects returned (see [Associated Objects](#associated-objects) below). Otherwise the data is returned as-is, except for dates which are converted into Python `datetime.datetime` objects.

Note: The LiquidPlanner REST API requires the data to be wrapped with the single entity name. For example `{'client': {'name': 'My Client'}}`. This library takes care of the outer part, so you only need to worry about `{'name': 'My Client'}}`.

```python>>> client = lp.clients.create({'name': 'My Client'})```

### Updating

Updating records is similar to creating, but the record id must be supplied.

The objects returned by `all()` and `get()` look and behave like Python `dict`s, but have a few properties available that allow access to associated objects. These properties have all the functionality of the main API endpoints.

Note: This functionality is not available when you use the `include` parameter to make associated objects available for an `all()` or `get()` request. Only the outer object(s) have associated objects available.

### Convenience Methods

For certain objects, the API supports various convenince methods. The wrapper does not attempt to filter the convenience methods to their applicable object types, it is up to the developer to use the Liquid Planner API Guide.