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

Três alterações lançadas este mês 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 um artigo próprio, mas juntas cobrem o tipo de organizaçã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 de forma programática com DELETE /signing-requests/{id}. Isto aplica-se apenas a pedidos que ainda não foram enviados. Assim que um pedido é enviado, este permanece no caminho de cancelamento, o que mantém o rasto de auditoria intacto para qualquer documento que um signatário já possa 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, 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.

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 subscrever este evento 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 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 de sessão do signatário mais forte 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 móvel 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 para reenvio de 60 segundos.

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 ligações de assinatura existentes continuam a funcionar. O novo comportamento de expiração aplica-se simplesmente por cima.

A razão pela qual isto é importante prende-se com 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 de segurança. Uma janela de inatividade estrita aliada a 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 o HIPAA e o SOC 2.

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

Eliminar um domínio de envio de email principal ou único

A eliminação de um domínio personalizado de envio de email costumava estar bloqueada quando este era o seu domínio principal 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 o principal.

Depois de o eliminar, o envio de emails volta para o remetente predefinido da empresa e, em seguida, para o predefinido da plataforma se nenhum remetente da empresa estiver definido. Para mudar para um novo domínio personalizado de forma limpa, basta adicionar o novo, verificá-lo e defini-lo como principal. Já não está preso a manter um domínio desatualizado apenas porque a API não lhe permitia remover o último.

Esta é uma pequena alteração, mas elimina 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 dos pedidos e respostas 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 consumos mínimos mensais, sem contratos.