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 comum: mais controlo operacional sobre os pedidos, sessões e domínios que a sua integração gere. Nenhuma delas é suficientemente grande para merecer uma publicação própria, mas juntas cobrem o tipo de organização interna que importa quando já se 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 registo de auditoria intacto para tudo o que um signatário possa já ter visto.

Uma chamada bem-sucedida devolve um 200 com o signing_request_id e um carimbo de data/hora deleted_on. Se tentar eliminar um pedido que já foi enviado, obtém 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.

Existe 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 fazer consultas recorrentes (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 de forma especulativa 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 estrito. 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 tempo de espera de 60 segundos para novo envio.

Isto apenas afeta pedidos onde require_otp_verification está ativado. 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 hiperligações de assinatura existentes continuam a funcionar. O novo comportamento de expiração é apenas aplicado adicionalmente.

A razão pela qual isto é importante são os dispositivos partilhados e públicos. Se um signatário abrir um documento confidencial num computador que não é seu e se afastar, uma sessão que nunca expira é um risco. Uma janela de inatividade estrita acrescida de um limite máximo limita o tempo em que essa janela permanece aberta. Se lida com acordos que acarretam expectativas reais de confidencialidade, 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 constam da entrada de atualizações da plataforma de 29 de maio, com a definição OTP subjacente documentada a partir da versão API v1.09.00.

Eliminar um domínio de envio de e-mail principal ou único

A eliminação de um domínio personalizado de envio de e-mail costumava estar bloqueada quando este era o seu domínio principal ou único. Essa restrição desapareceu. O método DELETE nos pontos de extremidade (endpoints) de domínio da empresa ou do espaço de trabalho funciona agora independentemente de o domínio ser o principal.

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, caso não esteja configurado nenhum remetente da empresa. Para migrar de forma limpa para um novo domínio personalizado, basta adicionar o novo domínio, verificá-lo e defini-lo como principal. Já não fica obrigado a 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 atrito real para quem estiver a migrar domínios. A migração de domínios não devia 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.049 por envelope (5¢ USD), sem mínimos mensais, sem contratos.