Redirect or native: where the media break really happens
A white-label signature API should do one simple thing: let your users sign without noticing that another vendor sits behind it. In practice this fails at an inconspicuous point, the handover. Your product creates a document, sends the user to a foreign system, and at some point they return, or not. Between those two points lies the media break: brand, language, navigation, error handling and state all change responsibility at once.
The key is the distinction between visual and functional white-label. Visual white-label means a foreign portal wears your logo and colours. That beats nothing, but it remains a portal. The user sees a different address in the browser bar, different mail senders, different error texts. Functional white-label means the signing flow runs inside your product logic: you decide when it starts, how it looks, which steps it has and what happens afterwards. That is the one hard distinction of this article.
Why is this decisive for multi-tenant SaaS? Because your customers have brands of their own. A property manager using your software for twelve housing companies wants each company to have signatures under its own identity. A redirect to a uniform portal destroys that differentiation, and it raises questions: who is this vendor, why am I getting mail from a foreign domain, is this phishing? Trust is a core topic with signatures, and every irritation costs completions.
A second effect is less visible but more expensive: loss of context. While the user is in the foreign portal, your product does not know their progress. You cannot offer help, answer questions in the document or trigger a reminder at the right time without first pulling data from the portal. Teams resort to polling or manual reconciliation, and that is where inconsistencies come from, such as a contract showing as open in the ERP although it was signed long ago.
The native variant avoids these breaks by letting the signing flow work as a service behind your interface. You call the API to create a transaction, register signers and hand over documents. The presentation of steps stays with you or in embedded components that follow your design. State returns through events. The user never leaves your software, and your system stays the source of truth. A related pattern in ERP settings is described in silent tech: signing inside ERP surfaces.
The video shows what a white-label flow looks like inside a foreign interface and how little the user notices of the vendor in the background. Watch the transition between host software and signing step: it is the yardstick for your own integration.
There are legitimate reasons for redirects. For one-off processes where a team wants to start fast and brand is secondary, a portal is pragmatic. For rare signatures with very high evidentiary weight a dedicated interface can also make sense. For ISVs with recurring use, several tenants and a product ambition it does not. For the requirements view, see the checklist in white-label requirements for ISVs.
Multi-tenant: one API, many brands
Tenancy is where an integration becomes a product building block. A signature API that knows only one brand forces workarounds: separate accounts per customer, hand-maintained templates, separate credentials. That scales at three customers and breaks at three hundred. An API with real tenant separation models your customers as separate units that keep brand, templates, sender, language and access rights apart, while you build the integration only once.
What belongs to a tenant-capable model? First, brand configuration: logo, colours, sender address of emails, texts in the interface and notifications. Second, templates and fields per tenant, so one customer's contracts never mix with another's. Third, permissions: who may create transactions, who may view them, who may export documents? Fourth, data separation, because a tenant must under no circumstances see another's data, neither in the interface nor in reports nor in logs.
Architecturally, carry the tenant identifier consistently through the whole chain. Every transaction, document and event receives your system's tenant ID as a reference. That lets you route webhooks unambiguously, filter reports and handle privacy requests precisely. Such an identifier costs an hour in design and saves weeks later when a customer asks which transactions belong to their account.
A frequent mistake is solving tenant traits in the frontend and ignoring them in the backend. A logo in the interface does not replace sender separation for emails. A tenant filter in a list does not replace an access check in the API. Test specifically whether access to another tenant's transactions is refused, even if someone guesses IDs. That is standard hygiene in any multi-tenant system and especially important for signature data, which holds confidential contracts.
Language belongs here as well. Tenants in different markets want texts in their language, with their form of address and legal tone. That affects not only interfaces but also invitation mails, reminders and notices before signing. A clean solution separates content from logic so you can maintain texts per tenant and language without changing code. Especially for notices on signature levels, such as the difference between SES, AES and QES, wording should be agreed and versioned.
In rolling out new tenants, automation shows its value. If every setup triggers a support ticket, tenant creation becomes a bottleneck. Better is onboarding that creates brand, templates and rights through the API or an admin interface and that you offer as part of your own customer onboarding. How the start via sandbox and reference works is in the developer hub, and typical patterns are in from sandbox to your first QES path.
Finally, tenancy is a compliance question. Regulated customers ask whether their data is logically separated, how long it is retained and who can technically access it. If you can answer these from your tenant model, you are a step ahead in sales. More in DORA Article 30 and the API audit trail, which shows how events become evidence.
Webhooks as the state bridge between signing and product
The media break has a second, invisible side: the data break. Even if the interface is seamless, your system must know what happened in the signing flow. Webhooks are the bridge. Instead of your code regularly asking whether a document is signed, the API reports state changes actively to an endpoint you provide. That saves load, reduces latency and avoids the inconsistencies of polling.
Typical events are: transaction created, invitation sent, document opened, identification completed, signature given, transaction completed, declined, expired or revoked. Your task is to translate each event into a state in your own data model. A contract that stands at “awaiting signature” in the product changes to “signed” on the completion event, triggers downstream processes such as filing in document management or releasing a service, and logs the change.
For this to work reliably you need three properties. Idempotency: the same webhook may arrive several times, and your system must process it without double booking. Order tolerance: events can arrive out of sequence, so check state transitions against an allowed order instead of overwriting blindly. Replayability: if your endpoint is briefly unreachable, the event must be deliverable later. We cover the details in webhook state management for e-signature events.
For white-label another point matters: the webhook must carry the tenant reference. Without a reference to your tenant and business object you must look things up, which creates error sources. So pass your own identifiers when creating a transaction and find them again in the webhook. That simplifies routing, reporting and troubleshooting, and it makes your integration robust against timing changes in the flow.
Security is part of it. A webhook endpoint is a publicly reachable entry into your system and should verify authenticity, for instance through signatures or shared secrets, limit requests and process only the fields it needs. Log every incoming webhook with time, source and processing result. That log is also your audit material when customers want to trace the process. Guidance on security is available from the BSI.
Hosting frame and jurisdiction for the signing flow
White-label means your brand stands behind the signature. That also makes you responsible for the question where the data sits. Customers from regulated industries rightly ask about location and ownership. Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems, a European operation under European law. For your communication that is a clear, verifiable sentence instead of a platitude.
Why does this matter especially for white-label? Because your customers do not see the vendor behind your brand. They trust you, and you must answer when someone asks about the background. If the answer is “a US group with a data centre in the EU”, the follow-up about the Cloud Act often comes. If it is “a European operator under European law”, the topic is usually settled. Background is in white-label e-signature on the Open Sovereign Cloud and Cloud Act vs data sovereignty.
Be precise in wording. Hosting on OSC is a statement about operations and jurisdiction of the platform, not a certification of your product and no replacement for your own data protection review. Document in your data processing agreement which data categories arise in the signing flow, and keep that information uniform across tenants. A uniform location is an advantage: it simplifies your evidence considerably compared with individual special paths per customer.
For customers with special requirements who cannot accept even the sovereign cloud, the option remains to run the signing flow in their own data centre. That is a different operating mode with its own requirements and should not be promised as standard in sales. We discuss it case by case. For most SaaS scenarios operating on OSC suffices, and it can be adopted as a uniform answer in your security documentation.
For the legal classification of signature levels, see the eIDAS Regulation. Sign2x supports SES, AES and QES. We are not a qualified trust service provider, and for QES the qualification runs through a partner QTSP such as Sign8. Your white-label communication should not obscure that but inform users at the right point about the level that applies to their transaction. An introduction is in SES, AES and QES in SaaS.
Rollout patterns: from pilot flow to tenant fleet
A white-label rollout works best in steps that each address one risk. Start with a pilot flow: one document type, one tenant, one signature level. The aim is not breadth but learning. You check whether your interface carries the process, whether webhooks are handled cleanly and whether support can answer the typical questions. Only when these three are stable is scaling worthwhile.
The second step is tenant expansion. Create a template for onboarding new tenants: brand configuration, default templates, rights, test transaction. Automate what repeats. For every new tenant check the sender domain and email delivery, because that is where most surprises arise when messages land in spam. Run a test with real users per tenant before going live.
The third step is level expansion. Many flows start with SES or AES and add QES when a use case demands it, for example in real estate, HR or certain financial products. Because the API structure stays the same, mainly the upstream identification step and the role of the partner QTSP change. Plan time for alignment and tests, and explain to users in plain words what changes. For AML-adjacent scenarios see AML, identification and QTSP for e-signature.
Define metrics alongside: completion rate, time from invitation to signature, drop-off points, support requests per transaction. Not to compare with other vendors' numbers but to improve your own flow. A baseline before the switch shows what removing the media break really brings and gives you arguments for sales and management. We quote no blanket improvement figures, because they depend on your starting point.
Finally, a note on communication. Inform existing customers in time when the flow changes and explain in two sentences what improves for them. Maintain help texts in the help centre so support and users speak the same language. And collect feedback systematically: the best improvements rarely come from workshops but from the tickets of the first four weeks. Scenarios are under use cases, more in-depth articles in the Sign2x blog.
If you want to know how far your current flow is from a native white-label solution, look at the developer hub, which describes the building blocks, and have a short conversation about your use case. For first orientation the Sign2x quiz also helps. We tell you openly where a native solution adds value and where a simple path suffices.
Start your white-label flow in the developer hub
Related reading: the sovereign e-signature alternative from Germany and API-first alternatives without iframe friction. Legal foundations on data protection are in the GDPR.
Frequently asked questions
What is the difference between visual and functional white-label?
Visual white-label puts your logo and colours on a foreign portal. Functional white-label lets the signing flow run in your product logic: you control start, presentation, steps and follow-up processes.
Why do webhooks matter for white-label?
They report state changes actively to your system. Your product stays the source of truth without polling. Idempotency, order tolerance and replayability are essential.
How are several tenants with their own brand modelled?
Through a multi-tenant API with separate brand configuration, templates, rights and data. Every request carries your tenant identifier so events and documents can be assigned unambiguously.
Where is Sign2x hosted?
On the Open Sovereign Cloud (OSC) from T-Systems. For customers with special requirements, operation in their own data centre is possible case by case.
Is Sign2x a qualified trust service provider?
No. Sign2x supports SES, AES and QES as an API layer. For QES the qualification runs through a partner QTSP such as Sign8.
