Guias

Como fazer White-Label de uma API de Assinatura de Documentos no seu Produto SaaS

Escrito por

Conteúdo

"Substitua 'Firma.dev' pelo texto 'O Seu Logotipo'. Ícone de mão coloca o logotipo com uma seta e o aviso 'Coloque a sua marca aqui!'"

Procura a análise completa? Este artigo abrange os conceitos e decisões fundamentais. Para um passo a passo detalhado de todas as funcionalidades de white-labeling, incluindo logótipos, personalização de cores, modelos de e-mail personalizados, endereços de remetente e exemplos de código, consulte The Complete Guide to White-Label E-Signatures for SaaS.

Se está a integrar uma API de assinatura de documentos no seu produto, os seus clientes não devem sentir que estão a utilizar o software de outra pessoa. A experiência de assinatura deve ter o aspeto e a identidade do seu produto, não os de uma ferramenta de terceiros.

O white-labeling torna isso possível. Mas a maioria dos programadores pensa que o white-labeling significa apenas colocar o seu logótipo em algo. Na prática, é mais subtil. Uma integração de API de assinatura digital totalmente personalizada envolve personalização visual, personalização de e-mails, controlo de notificações e interfaces integradas — e nem sempre precisa de todas. Para ver o âmbito total do que pode personalizar, consulte a visão geral das funcionalidades da white-label e-signature API.

Este guia detalha o que faz cada camada, quando a utilizar e como implementar uma API de assinatura de PDF em formato white-label que se ajuste ao seu produto.

O que o white-labeling significa realmente para as assinaturas eletrónicas

Quando um cliente assina um documento através da sua aplicação, vários pontos de contacto contêm a marca:

  • A própria interface de assinatura (logótipo, cores, layout)

  • O e-mail que os notifica de que um documento está pronto para ser assinado

  • O endereço do remetente e o modelo de e-mail

  • As notificações de conclusão e de lembrete

  • Quaisquer termos legais ou passos de aceitação

Por predefinição, a maioria das APIs de assinatura personaliza tudo isto com o seu próprio nome. O White-labeling permite-lhe substituir essa marca pela sua, ou removê-la por completo.

O objetivo é simples: os seus clientes interagem com a sua marca ao longo de todo o fluxo de trabalho de assinatura. Nunca veem o fornecedor da API subjacente.

As quatro camadas de white-labeling

Camada 1: Personalização visual

O impacto mais imediato. Carregue o seu logótipo, defina a sua paleta de cores e oculte completamente a marca do fornecedor da API da experiência de assinatura.

Com o Firma.dev, pode controlar seis definições de cor (destaque principal, texto do primeiro plano, fundo, cor do cartão e cor do limite) e pode carregar logótipos tanto ao nível da empresa como do espaço de trabalho. Para produtos SaaS multi-tenant, isto significa que cada um dos seus clientes pode ter a sua própria identidade visual distinta no fluxo de assinatura.

Ative show_custom_branding_only e a interface de assinatura parecerá ter sido criada pela sua equipa. Sem logótipos de terceiros, sem esquemas de cores desconhecidos.

Esta camada demora minutos a implementar e tem o maior impacto visível. Comece por aqui, mesmo que planeie adicionar as outras camadas mais tarde.

Camada 2: Domínios de e-mail e modelos personalizados

Em vez de enviar pedidos de assinatura de noreply@signatureprovider.com, os e-mails vêm do seu domínio, como documents@yourcompany.com. Também controla a parte local do endereço do remetente (a parte antes do @), pelo que pode utilizar noreply, signing, contracts ou o que melhor se adaptar ao seu produto.

Além do remetente, pode personalizar os próprios modelos de e-mail. O Firma.dev suporta modelos HTML personalizados para 11 tipos de e-mail (convites de assinatura, conclusões, lembretes, expirações e muito mais), com marcadores de posição dinâmicos para nomes de signatários, ligações de assinatura, logótipos de empresas e detalhes da equipa. Defina modelos ao nível da empresa para garantir consistência e substitua-os por espaço de trabalho sempre que necessário.

Para produtos SaaS multi-tenant, os domínios de e-mail ao nível do espaço de trabalho significam que cada um dos seus clientes pode enviar a partir do seu próprio domínio. Uma plataforma de gestão de propriedades poderia fazer com que os e-mails de assinatura fossem enviados de leases@buildingname.com para cada propriedade.

Se procura uma implementação rápida, consulte How to White-Label Your E-Signature Emails and Signing Links para obter um passo a passo detalhado.

Camada 3: Controlo de notificações

E-mails personalizados e modelos personalizados são bons. O controlo total sobre as notificações é melhor.

A maioria das APIs de assinatura digital envia e-mails automáticos para pedidos de assinatura, confirmações de conclusão, avisos de expiração e notificações de cancelamento. Uma configuração de white-label permite-lhe desativar qualquer um ou todos estes e-mails por pedido de assinatura.

Por que razão gostaria de os desativar? Porque pode querer:

  • Enviar ligações de assinatura através da sua própria infraestrutura de e-mail

  • Integrar notificações nos fluxos de comunicação existentes com os clientes

  • Controlar o timing dos lembretes e acompanhamentos

  • Despoletar e-mails com base na sua própria lógica de negócio

Quando desativa os e-mails da API, obtém os URLs de assinatura diretamente da API e distribui-os como desejar. Isto é especialmente útil se já tiver uma infraestrutura de e-mail transacional (SendGrid, Postmark, Customer.io) e pretender que as notificações de assinatura fluam através do mesmo sistema.

Camada 4: Experiências de assinatura integradas

Esta é a solução completa de white-label. Em vez de redirecionar os utilizadores para uma página de assinatura de terceiros, integra a interface de assinatura diretamente na sua aplicação.

Com a assinatura integrada, todo o fluxo de trabalho acontece dentro do seu produto. Os utilizadores nunca saem do seu domínio. Veem o seu cabeçalho, a sua navegação, o seu design. A interface de assinatura aparece como uma parte integrada da sua aplicação, apresentada com o seu logótipo e cores.

A maioria das APIs de assinatura de PDF oferece componentes integráveis para:

  • Assinatura: O fluxo real de assinatura de documentos

  • Edição de modelos: Permitir que os utilizadores definam campos de assinatura e marcadores de posição

  • Configuração de pedidos de assinatura: Configurar destinatários, ordem e opções

As experiências integradas normalmente utilizam autenticação JWT (JSON Web Token). O seu backend gera um token de curta duração e o frontend carrega o componente integrado com esse token. Sem chaves de API expostas ao cliente.

A personalização do fluxo integrado vai agora um passo além da própria interface. O texto do botão apresentado ao signatário é personalizável por idioma, pelo que os botões dentro da sua visualização de assinatura integrada podem corresponder à linguagem do seu produto em vez de herdarem predefinições genéricas. Consulte os rótulos de botão de assinatura personalizáveis para saber como configurá-los.

Para produtos SaaS onde a assinatura de documentos é uma funcionalidade principal, a assinatura integrada geralmente compensa o esforço de implementação. O seu produto parece mais coeso e mantém o controlo total sobre a experiência do utilizador.

Escolher a abordagem certa

Nem todas as integrações precisam de um white-labeling completo. Eis como decidir:

Logótipo, cores e e-mails personalizados funcionam bem quando a assinatura é uma funcionalidade secundária. Os seus clientes obtêm uma experiência profissional e personalizada sem um esforço de desenvolvimento significativo. A implementação demora algumas horas, maioritariamente configuração de DNS e algumas chamadas de API para a personalização visual.

O acima indicado + modelos de e-mail personalizados adapta-se a produtos onde pretende comunicações personalizadas sem substituir a sua infraestrutura de e-mail. Personaliza o conteúdo e o HTML dos e-mails de assinatura enquanto o Firma.dev trata do envio. Isto adiciona uma ou duas horas de trabalho nos modelos.

O acima indicado + controlo de notificações é a escolha certa quando pretende deter totalmente a camada de comunicação. Pode ter requisitos de conformidade específicos em relação aos e-mails ou pretender que as notificações de assinatura fluam através do seu sistema transacional existente. Isto adiciona um ou dois dias de trabalho de integração.

Experiência integrada completa é a escolha certa quando a assinatura é central para o seu produto. Plataformas de RH, ferramentas de gestão de contratos, software imobiliário, sistemas de acolhimento na área da saúde. Se os seus clientes passam muito tempo em fluxos de trabalho de assinatura, a integração dessa experiência compensa. Conte com alguns dias a uma semana de trabalho de integração, dependendo de quantos componentes integrar.

Considerações de implementação

Algumas coisas a considerar antes de começar:

  1. Espaços de trabalho e multi-tenancy. Se está a construir um produto SaaS multi-tenant, procure uma API de assinatura de documentos que suporte espaços de trabalho de clientes. Cada um dos seus clientes obtém um ambiente isolado com os seus próprios modelos, histórico de assinaturas, personalização de marca e (opcionalmente) domínio de e-mail. Isto mantém os dados devidamente separados sem ter de construir a isolação de inquilinos por si próprio.

  2. A hierarquia de definições. As definições de personalização de marca no Firma.dev funcionam em cascata: o espaço de trabalho sobrepõe-se à empresa, a empresa sobrepõe-se às predefinições. Isto significa que define a personalização ao nível da empresa uma vez e apenas configura sobreposições ao nível do espaço de trabalho quando necessário. Definir um valor de espaço de trabalho como null herda do nível da empresa.

  3. Segurança. Gere tokens JWT no seu backend, nunca no código do lado do cliente. Mantenha a expiração do token curta (1 a 4 horas é o habitual). Valide as origens das mensagens do iframe se estiver a gerir eventos de componentes integrados.

  4. Conformidade. O white-labeling não altera a validade legal das assinaturas. Uma API de assinatura digital bem concebida mantém a conformidade com ESIGN, UETA e eIDAS, independentemente da personalização da marca. Certifique-se de que o seu fornecedor suporta os quadros regulamentares relevantes para os seus clientes.

  5. Custo. As plataformas de assinatura empresariais cobram frequentemente taxas elevadas pelas funcionalidades de white-labeling. Alguns fornecedores incluem o white-labeling em todos os níveis de preços. O Firma.dev inclui todas as capacidades de white-labeling no modelo de pagamento por utilização a €0,049 por envelope (~5¢ USD), sem contratos ou mínimos.

Como começar

If you're evaluating document signature APIs for a white-labeled integration, start by mapping out which touchpoints matter most to your customers. Do they care about email branding? Do they need the signing flow embedded? The answers will guide your implementation scope. For the broader strategic picture across single-brand and multi-tenant setups, see the complete guide to white-label e-signatures for SaaS.

Para um passo a passo técnico detalhado, o Firma.dev White Labeling Guide abrange domínios de e-mail personalizados, definições de notificação e componentes integrados com exemplos de código.

Pronto para construir? Obtenha a sua chave de API e comece a integrar em horas, não em semanas.

  1. Cabeçalho

Imagem de Fundo

Pronto para adicionar assinaturas eletrónicas à sua aplicação?

Comece gratuitamente. Não é necessário cartão de crédito. Pague apenas 0,049 € por envelope quando estiver pronto para começar.

Imagem de Fundo

Pronto para adicionar assinaturas eletrónicas à sua aplicação?

Comece gratuitamente. Não é necessário cartão de crédito. Pague apenas 0,049 € por envelope quando estiver pronto para começar.

Imagem de Fundo

Pronto para adicionar assinaturas eletrónicas à sua aplicação?

Comece gratuitamente. Não é necessário cartão de crédito. Pague apenas 0,049 € por envelope quando estiver pronto para começar.