Atualizações de Produtos, junho de 2026: Limpeza de Rascunhos, Segurança de Sessão e Gestão de Domínios

Este mês foram lançadas três alterações que partilham um fio condutor: mais controlo operacional sobre os pedidos, sessões e domínios que a sua integração gere. Nenhuma delas é suficientemente grande para ter uma publicação própria, mas juntas cobrem o tipo de manutenção que importa quando já tem um volume real a passar pela API. Eis o que chegou.

Eliminar pedidos de assinatura não enviados através da API

Agora pode eliminar rascunhos de pedidos de assinatura programaticamente com DELETE /signing-requests/{id}. Isto aplica-se apenas a pedidos que ainda não foram enviados. Uma vez enviado o pedido, este permanece no caminho de cancelamento, o que mantém o histórico de auditoria intacto para qualquer documento que um signatário já possa ter visto.

Uma chamada bem-sucedida devolve um código 200 com o signing_request_id e um carimbo de data/hora deleted_on. Se tentar eliminar um pedido que já foi enviado, receberá um 409 em vez de uma falha silenciosa, para que o seu código possa ramificar-se claramente entre eliminar e cancelar. Um ID em falta ou desconhecido devolve 404.

Há também um novo evento de webhook signing_request.deleted que é acionado sempre que um pedido é eliminado através da API. Se espelhar o estado da assinatura na sua própria base de dados, pode subscrevê-lo e manter os seus registos sincronizados sem necessidade de consultas periódicas (polling).

O caso de utilização óbvio é a limpeza. Se a sua integração cria rascunhos como parte de um fluxo de criação e posterior revisão, ou gera pedidos especulativamente e descarta os que não são utilizados, já não precisa de deixar rascunhos abandonados acumulados. Pode eliminá-los como parte do mesmo fluxo que os criou.

Isto foi lançado na API v1.22.0.

Expiração mais forte da sessão do signatário em pedidos protegidos por OTP

Para pedidos que têm a verificação OTP ativada, as sessões do signatário expiram agora de acordo com um calendário fixo. Uma sessão termina após uma janela de inatividade flutuante de 4 horas, ou 12 horas após a última verificação como limite máximo, o que ocorrer primeiro. Quando uma sessão expira, o signatário volta a verificar-se com um novo código de 6 dígitos. Esse código é válido por 10 minutos, permite 5 tentativas e tem um intervalo de recarga de 60 segundos.

Isto apenas afeta os pedidos onde a opção require_otp_verification está ativada. Se não utiliza a verificação OTP, nada muda para si. Para os pedidos que a utilizam, não é necessária qualquer ação por parte do remetente e as ligações de assinatura existentes continuam a funcionar. O novo comportamento de expiração é apenas aplicado adicionalmente.

A razão pela qual isto importa são os dispositivos partilhados e públicos. Se um signatário abrir um documento confidencial num computador que não é dele e se afastar, uma sessão que nunca expira é um risco de segurança. Uma janela de inatividade fixa mais um limite máximo limitam o tempo que essa janela permanece aberta. Se lida com acordos que exigem confidencialidade real, isto reforça a sua postura e ajuda-o a cumprir as expectativas de controlo de acesso exigidas por estruturas como a HIPAA e a SOC 2.

Os detalhes encontram-se na entrada de atualizações da plataforma de 29 de maio, com a configuração OTP subjacente documentada a partir da API v1.09.00.

Eliminar um domínio de envio de e-mail primário ou único

A eliminação de um domínio personalizado de envio de e-mail costumava ser bloqueada quando este era o seu domínio primário ou único. Essa restrição foi removida. O método DELETE nos endpoints de domínio da empresa ou do espaço de trabalho funciona agora independentemente de o domínio ser primário.

Depois de o eliminar, o envio de e-mails de saída reverte para o remetente predefinido da empresa e, em seguida, para o predefinido da plataforma se não estiver definido nenhum remetente da empresa. Para migrar para um novo domínio personalizado de forma limpa, adicione o novo, verifique-o e defina-o como primário. Já não precisa de manter um domínio desatualizado apenas porque a API não lhe permitia remover o último.

Esta é uma pequena alteração, mas remove um ponto de fricção real para quem está a migrar domínios. A migração de domínios não deve exigir um pedido de suporte, e agora já não exige.

Isto foi lançado na API v1.22.1.

Começar

As três alterações já estão ativas na API. Os detalhes completos do pedido e da resposta encontram-se no registo de alterações da API.

Comece a utilizar o Firma.dev gratuitamente, sem necessidade de cartão de crédito. Pague apenas o que utilizar a $0.029 por envelope (2.9¢ USD), sem mínimos mensais, sem contratos.