Pular para o conteúdo principal

Documentation Index

Fetch the complete documentation index at: https://zapo.to/llms.txt

Use this file to discover all available pages before exploring further.

Uma store é onde o zapo persiste tudo o que uma sessão precisa para sobreviver a um reinício: credenciais de pareamento, estado do protocolo Signal, coleções de app-state e, opcionalmente, seu arquivo de mensagens/threads/contatos. Você constrói uma com createStore e a passa para o client.
import { createStore } from 'zapo-js'
import { createSqliteStore } from '@zapo-js/store-sqlite'

const store = createStore({
  backends: {
    sqlite: createSqliteStore({ path: '.auth/state.sqlite', driver: 'auto' })
  },
  providers: {
    auth: 'sqlite',
    signal: 'sqlite',
    senderKey: 'sqlite',
    appState: 'sqlite',
    messages: 'sqlite',
    threads: 'sqlite',
    contacts: 'sqlite',
    privacyToken: 'sqlite'
  }
})

O modelo

O createStore separa backends (onde os dados ficam) de providers (qual backend cada domínio usa). Isso permite misturar backends — por exemplo, manter o estado quente do signal no Redis enquanto arquiva mensagens no Postgres.
createStore({
  backends: {
    redis: createRedisStore({ redis }),
    postgres: createPostgresStore({ pool })
  },
  providers: {
    auth: 'redis',
    signal: 'redis',
    senderKey: 'redis',
    appState: 'redis',
    privacyToken: 'redis',
    messages: 'postgres',
    threads: 'postgres',
    contacts: 'postgres'
  }
})
Qualquer domínio que você omitir usa por padrão o backend memory embutido — nenhuma entrada em backends é necessária.

Domínios persistidos

Estes mantêm o estado necessário para manter uma sessão viva. Apoie-os com um backend durável em produção.
DomínioMantém
authCredenciais de pareamento e identidade do dispositivo. Persista isto.
signalSessões do Signal (guarda-chuva sobre as sub-stores abaixo).
preKeyPre-keys do Signal.
sessionSessões do Signal.
identityChaves de identidade do Signal.
senderKeySender keys de grupo.
appStateColeções de app-state (silenciar, fixar, ler, arquivar, …).
privacyTokenTokens de contato confiável / privacidade.

Domínios de arquivo opcionais

Estes aceitam 'none' para desabilitar a persistência por completo:
DomínioMantém
messagesArquivo de mensagens (B | 'memory' | 'none').
threadsMetadados de thread.
contactsDiretório de contatos.

Domínios de cache

Configurados em cacheProviders e usam por padrão memória limitada com TTLs:
DomínioMantém
retryFila de retentativa de mensagens de saída.
groupMetadataCache de metadados de grupo.
deviceListCache da lista de dispositivos.
messageSecretCache de message-secret para addons.
createStore({
  backends: { sqlite },
  providers: { /* ... */ },
  cacheProviders: { groupMetadata: 'sqlite', deviceList: 'sqlite' },
  memory: {
    cacheTtlMs: { groupMetadataMs: 600_000, deviceListMs: 600_000 }
  }
})

Backends

SQLite

@zapo-js/store-sqlite — local, processo único.

PostgreSQL

@zapo-js/store-postgres — distribuído, relacional.

MySQL

@zapo-js/store-mysql — distribuído, relacional.

Redis

@zapo-js/store-redis — cache + persistência.

MongoDB

@zapo-js/store-mongo — document store.

Memory

Embutido. Ótimo para testes; não sobrevive a um reinício.
Veja a referência de stores para as opções de config de cada backend.

Apenas memória (testes)

Para experimentos rápidos ou testes, omita backends por completo — cada domínio recorre à memória:
const store = createStore({})
const client = new WaClient({ store, sessionId: 'test' }, logger)
Uma store apenas em memória perde todas as credenciais ao reiniciar, então você pareia novamente a cada boot. Use um backend durável para qualquer coisa de longa duração.
Last modified on May 27, 2026