Welcome to Zooly docs
Zooly is an intellectual property marketplace designed to facilitate the licensing of likeness rights in the age of AI.
The platform enables celebrities, talents, musicians, models, influencers, and other public figures to register and offer their intellectual property (IP) for sale. Content creators can then search Zooly to find and purchase licensing terms from these rights holders.
At its core, Zooly connects IP sellers with buyers by providing standardized contract templates called "terms." These terms define the specific context, usage rights, and pricing under which a content creator can use a celebrity's likeness or intellectual property. This streamlined process makes it easier for rights holders to monetize their IP while enabling creators to legally leverage celebrity likeness in their content.
Zooly docs is the documentation platform for the Zooly project, providing comprehensive guides and references for developers working with the platform.
Use the search bar at the top header bar to find the documentation you need.
Zooly is a monorepo project organized into apps and packages. The platform is designed as a multi-tenant, multi-app, multi-domain, multi-package, multi-database, microservice-based system.
Some packages are shared across multiple apps, while others are specific to individual applications.
The project structure follows this organization:
packages folderapps folderThe auth app is a self-contained application responsible for authentication and authorization across the platform. It serves as an identity provider for other apps, handling all user authentication.
The main app database does not store user data—it only stores Accounts, which represent the tenants of the platform. An Account is owned by a User but can be shared with multiple Users.
By default, when a user logs in, they are automatically assigned to an Account based on their login ID. While users will be able to create multiple accounts in the future, this feature is currently hidden.
See Auth Overview for more details.
The platform implements multi-tenancy by automatically filtering all database queries by Account ID. To enforce this pattern, database access is exclusively handled through the db package access functions—the database object itself is never exported directly.
Here's how we enforce this pattern:
The access functions automatically apply tenant filtering when needed. They require an accountId parameter, and the build will fail if this parameter is not provided.
Important: Every React element div in client packages must include a data-testid attribute to enable automated testing.
Currency Convention: All monetary amounts across the project are stored and passed as integer cents (not dollars). Every variable, parameter, database column, and API field that represents money must use the Cent suffix (e.g. amountCent, platformFeeCent, zoolyFeeCent). This avoids floating-point precision issues and makes the unit unambiguous at every layer.
See DB package for more details.
We use the types package to share type definitions across the project.
Database schemas are defined in the db package. Each schema includes a _typeCheck declaration to verify type compatibility between the schema and the corresponding type definition. If a schema doesn't match its type, the build will fail with a compile-time error.
Example:
...
import type { Account } from "@zooly/types";
/**
* Account table schema
*/
export const accountTable = pgTable("account", {
...
// Type compatibility check (will error at build time if incompatible)
const _typeCheck: Account = {} as typeof accountTable.$inferSelect;