The Platform Beyond Its Core: Integrations and Plugins
This chapter examines how Ever Gauzy extends its shared operational context beyond the records built into the core. The focus is the difference between an installed integration and a plugin: an integration maps an external system into an organization’s data and policies, while a plugin can add the modules, entities, events, and user interface that make a capability part of Gauzy. That distinction helps readers follow a GitHub issue into a Gauzy task and assess extensibility without confusing it with sandboxing or conflict-free automation.
An integration is a data contract, not an OAuth button
An OAuth login proves that an external account has been connected. It does not tell Gauzy which organization owns that connection, which kinds of external records should be synchronized, or how an external record relates to a Gauzy record. The integration model addresses those questions through several layers.
An integration catalog entry describes a provider such as GitHub or another connected service. An installed integration is represented separately for a tenant and organization. That installed record owns provider settings, entity-level synchronization settings, a last-synchronized timestamp, and integration maps. The map records the external entity type and source identifier alongside the Gauzy identifier. Together, these records establish scope, policy, and identity.
The separation is important for the project story. Northstar Studio might connect GitHub for one organization but not another. It might allow issue synchronization for one project while keeping another project manual. It might synchronize issues and labels but not every possible external object. A source identifier can then be mapped to the Gauzy task that represents it, reducing the chance that repeated synchronization creates duplicate work.
The mapping is not a universal merge engine. External systems and Gauzy can both change a record. A source can be deleted, renamed, rate-limited, or changed in a way the integration does not understand. A label may have a different meaning in another system. A last-synced time tells an operator when a synchronization was recorded; it does not prove that every external change has been reconciled. Integration policy and failure behavior remain part of the provider implementation.
This gives an integration three separate questions to answer. Where is it installed? The tenant and organization scope determine whose connection and data are involved. What is allowed to move? Entity settings and project-level choices determine whether issues, labels, or other records are synchronized. How is identity preserved? The external type and source ID are mapped to a Gauzy ID under the installed integration. A provider that answers only the first question can connect successfully while still producing duplicates, overbroad imports, or records that cannot be explained later.
The mapping also affects ownership. Northstar may decide that GitHub owns issue discussion while Gauzy owns employee assignment, billability, timesheets, and client invoicing. Or it may treat Gauzy task status as the operational state and use GitHub only as an engineering view. The repository supports the relations and synchronization commands needed for such arrangements, but it does not impose a universal source of truth for every field. That rule must be explicit before two systems are allowed to update the same work.
How a GitHub issue crosses the boundary
Gauzy’s GitHub integration provides a concrete example. The plugin configures webhook handling, OAuth and authorization controllers, repository and issue entities, synchronization services, hooks, middleware, command handlers, and event subscribers.