Câmera ou foto, sem biblioteca pesada
A leitura funciona com o reconhecimento nativo do próprio navegador onde disponível, e recorre ao envio de uma foto em qualquer outro caso, sem nenhuma biblioteca de leitura embutida em nenhum dos dois casos.
QR e controle de acesso
Uma leitura, uma entrada. Sempre.
O resgate é uma única escrita condicional no banco de dados, não uma leitura seguida de uma escrita. Duas portarias lendo o mesmo código no mesmo segundo ainda assim só deixam uma pessoa passar.
- 1 atualização condicional Resgatar é uma única escrita SQL protegida pelo status atual do ingresso, nunca uma leitura seguida de uma escrita
- Desfazer fica fora do leitor Reverter um resgate é uma ação exclusiva do administrador, nunca disponível na própria tela de leitura
- Anular é definitivo Um ingresso anulado não tem volta. Não existe "desanular"
Quatro peças da porta.
Cada uma protege uma parte diferente do que acontece no momento em que um código é lido.
Resgatar, atomicamente
Marcar um ingresso como usado é uma única escrita, condicionada a ele ainda estar emitido. Duas leituras quase simultâneas do mesmo código, em duas portarias diferentes, nunca têm sucesso as duas.
Anular e desfazer, separados de propósito
Só o back office pode anular um ingresso ou desfazer um resgate, nunca a tela de leitura. Dar os dois poderes à equipe da portaria permitiria "desfazer" um ingresso usado na hora para deixar entrar uma segunda pessoa com o mesmo código.
Vouchers externos, baixados com segurança
Um arquivo de voucher nunca é servido a partir de uma URL pública. Todo download passa por uma rota autenticada que também verifica se o arquivo realmente pertence ao ingresso solicitado.
Como uma leitura vira uma decisão na porta
Cinco passos, toda vez que um código é lido ou digitado manualmente.
- 1
O código é buscado
Um código lido ou digitado manualmente é resolvido até seu ingresso, ou retorna um claro "não encontrado" sem indicar se esse código já existiu de alguma forma.
- 2
O status é verificado dentro da mesma escrita
O resgate é um único UPDATE com uma condição exigindo que o ingresso ainda esteja emitido. Se zero linhas forem afetadas, nada mudou, e o motivo é reportado de volta a partir de uma nova leitura logo em seguida.
- 3
Só uma leitura sempre vence a corrida
Como a verificação de status e a escrita acontecem como uma única operação atômica, duas portarias competindo para ler o mesmo código no mesmo instante nunca têm sucesso as duas.
- 4
Um evento é registrado de qualquer forma
Toda transição, bem-sucedida ou não, registra quem a disparou, de onde, leitura ou ação administrativa, e quando, para que uma entrada contestada sempre possa ser reconstruída.
- 5
Desfazer e anular ficam atrás do seu próprio portão
Reverter um resgate ou anular um ingresso existe apenas como uma ação do back office atrás de sua própria permissão, inteiramente separada da permissão que permite ler códigos na porta.
O que a porta realmente vê
Produto, opção, tipo de ingresso, data, posição no pedido, nome do comprador e status de cumprimento. Nunca um preço, nunca uma margem, nunca nada que a equipe da portaria não precise para tomar uma decisão.
POST /api/v1/tickets/redeem
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
{
"ticket_code": "AB12CD34EF",
"status": "redeemed",
"redeemed_at": "2026-08-14T10:00:00Z",
"position": 2,
"quantity": 3,
"product_name": "City Food Tour",
"buyer_name": "Jane Buyer",
"fulfillment_status": "not_required"
}200 Ingresso resgatado
Zero linhas afetadas ainda conta toda a história
Quando a atualização condicional não afeta nenhuma linha, isso sozinho não diz o porquê. O sistema imediatamente relê o ingresso para reportar a causa real: já resgatado, com um horário e quem o fez, ou anulado, em vez de uma falha genérica. Essa verificação acontece depois da escrita de propósito: fazê-la antes reabriria exatamente a corrida que a escrita atômica existe para fechar.
Perguntas frequentes
Não. O resgate é uma única escrita no banco de dados condicionada a o ingresso ainda estar emitido. A leitura que chegar primeiro ao banco de dados vence essa condição; a segunda encontra zero linhas afetadas e recebe "já resgatado" em vez disso.
Não pela tela de leitura. Desfazer um resgate existe apenas como uma ação do back office atrás de sua própria permissão. Deixar a mesma equipe que lê também desfazer abriria um caminho real para deixar entrar uma segunda pessoa com um código já usado.
Não. Anular é definitivo por projeto; não existe "desanular" em nenhum lugar do sistema. Uma anulação por engano precisa de um novo ingresso, não de uma reversão.
Não. A resposta de resgate é deliberadamente limitada ao que a equipe da portaria precisa para tomar uma decisão: produto, opção, tipo de ingresso, data, nome do comprador, posição dentro do pedido e status de cumprimento.
Eles nunca são servidos a partir de uma URL pública. Todo download passa por uma rota autenticada que também verifica se o arquivo realmente pertence ao ingresso solicitado, não só se quem pediu está autenticado.
Mais reservas. Mais canais. A mesma calma.
A Tiqory mantém disponibilidade, preços, pagamentos e acesso a trabalhar juntos enquanto a sua operação cresce. Conte-nos para onde vai; mostramos como chegar lá sem recomeçar.