Passwords should not be stored directly, they should be hashed.
The name field for venues is a timestamp in the schema. This seems to be an error and should be fixed.
The performer_id and venue_id fields in the bookings table don't have foreign key constraints.
The apispec specifies constraints for multiple fields in the return value of a /catalog/performers/ get performers call. They aren't enforced anywhere and should probably be removed.
There is a mismatch between the ER diagram and apispec that needs to be resolved; the user_type is a string in the apispec, but an int in the ER diagram.
The input for the create booking endpoints are inconsistent; they don't use any of the input fields besides the id.
The capacity_preference is an ambiguous name; it could be mistaken as a description rather than a numerical value and it's difficult to understand what exactly its purpose is.
There is a datatype inconsistency between the schema and the code; the fields concerning timestamps in the schema are of type string in the code.
The apispec documentation has a comment in the return value by the password field: / With timezone /. This seems to be accidentally placed there.
The bookings table id name is inconsistent with the other tables' id names; it is the only that is simple named id. This is mostly a nitpick but it would be good to maintain consistency with naming.
Better failure details can be added instead of "success": "false" for failed transactions.
The user_id field is inserted into the performers and venues tables in the code, but the schema doesn't have any user_id fields for either of those tables.
Passwords should not be stored directly, they should be hashed.
The name field for venues is a timestamp in the schema. This seems to be an error and should be fixed.
The performer_id and venue_id fields in the bookings table don't have foreign key constraints.
The apispec specifies constraints for multiple fields in the return value of a /catalog/performers/ get performers call. They aren't enforced anywhere and should probably be removed.
There is a mismatch between the ER diagram and apispec that needs to be resolved; the user_type is a string in the apispec, but an int in the ER diagram.
The input for the create booking endpoints are inconsistent; they don't use any of the input fields besides the id.
The capacity_preference is an ambiguous name; it could be mistaken as a description rather than a numerical value and it's difficult to understand what exactly its purpose is.
There is a datatype inconsistency between the schema and the code; the fields concerning timestamps in the schema are of type string in the code.
The apispec documentation has a comment in the return value by the password field: / With timezone /. This seems to be accidentally placed there.
The bookings table id name is inconsistent with the other tables' id names; it is the only that is simple named id. This is mostly a nitpick but it would be good to maintain consistency with naming.
Better failure details can be added instead of "success": "false" for failed transactions.
The user_id field is inserted into the performers and venues tables in the code, but the schema doesn't have any user_id fields for either of those tables.