Core Docs
Backend

Clientes e Regionais

Empresas que abrem vagas, suas regionais, contatos e benefícios oferecidos.

Módulo client (mais o catálogo benefit). Um Cliente pode ter várias Regionais; cada uma pode ter seus próprios Contatos e Benefícios (ou o cliente tem os seus, no nível raiz).

No código backend, Regional ainda aparece como ClientUnit.

Cliente (ClientEntity)

Campos: companyName, tradeName, personType (PJ/PF), cnpjCpf, taxRegime (SIMPLES_NATIONAL / PRESUMED_PROFIT / ACTUAL_PROFIT / NONE), address (embutido), contacts (1:N), benefits (1:N).

Endpoints (/gnoqcore/v1/client)

MétodoRotaPermissão
POST/client:create
GET/{id}, / (lista)client:read
PUT/{id}client:update
PATCH/{id}/restoreclient:update
DELETE/{id}/trash, /{id}/forceclient:delete

Regional (ClientUnitEntity)

Uma vaga pode estar ligada diretamente a um Client ou a uma ClientUnit (nunca as duas — ver Recrutamento). Campos: client (FK obrigatória), unitName, contacts (1:N), benefits (1:N).

Endpoints (/gnoqcore/v1/client-units)

MétodoRotaPermissão
POST/client_unit:create
GET/{id}, / (lista)client_unit:read
PUT/{id}client_unit:update
PATCH/{id}/restoreclient_unit:update
DELETE/{id}/trash, /{id}/forceclient_unit:delete

Contatos (ClientContactEntity)

Compartilhada entre Cliente e Unidade — o campo client ou clientUnit é preenchido (nunca os dois). Campos: name, email, position, phoneNumber, isPrimary.

Dois controllers com a mesma forma, um por nível:

RecursoBasePermissão
Contato de cliente/gnoqcore/v1/client/{clientId}/contactclient_contact:*
Contato de regional/gnoqcore/v1/client-units/{clientUnitId}/contactclient_unit_contact:*

Ambos suportam criar/atualizar em lote (POST/PUT recebem uma lista), GET por id, GET .../search paginado, e DELETE por id — sem /force (contato só tem soft delete).

Benefícios (benefit)

Catálogo (BenefitEntity: name, description) — somente leitura pela API (GET /gnoqcore/v1/benefit, sem permissão), populado via seed/admin direto no banco.

Cliente e Unidade associam benefícios do catálogo com um valor monetário específico via ClientBenefitEntity / ClientUnitBenefitEntity (chave composta clientId/clientUnitId + benefitId, campo value: BigDecimal). Não têm controller próprio — são geridos junto com o create/update de Cliente ou Unidade.

Upload de imagem (roadmap de vaga)

Não é parte deste módulo, mas é usado a partir dele: PATCH /vacancy/{id}/roadmap-image envia a imagem pro Supabase Storage (storage/application/service/SupabaseStorageService), que comprime (ImageCompressionService) e salva em {vacancyId}/{uuid}.{ext}, retornando a URL pública gravada em VacancyEntity.roadmapImageUrl. Só aceita PNG/JPEG (UnsupportedImageTypeException caso contrário) e tem limite de tamanho (ImageTooLargeException).

On this page