Maximising Efficiency with the Skribble API: Inside SBB's Power Automate Integration

Ditching manual signature requests for an automated flow is exactly the kind of project that pays for itself fast — and that's precisely what SBB (Swiss Federal Railways) built with Skribble.

In Skribble's first-ever API webinar, the team covered why the API drives the product, what changed in version 2, and how SBB automated signature requests for its infrastructure project audits using Microsoft Power Automate. You'll hear from David Fürsinger (Co-Founder & Chief Product Officer), Waldemar Dick (CTO & Co-Founder), Freddy Kaiser (Director of Strategic Initiatives), and Fabian Böhm from SBB, who built the integration himself and doesn't shy away from what didn't work on the first try.

What You'll Take Away

• Why Skribble treats the API as a first-class citizen — the same one the Skribble web app itself runs on
• What changed in API v2, and how little effort a migration from v1 actually takes
• How SBB automated signature requests for project portfolio audits using Power Apps and Power Automate — no custom backend required
• The real challenges SBB ran into with webhooks, secrets management, and reusability, and how they solved them
• Answers to live audience questions on webhooks, callback security, monitoring, and upcoming integrations

Why Skribble Takes an API-First Approach

David Fürsinger: Skribble is built on three product principles: workflows, an API-first approach, and a great user experience. We believe digital signing should combine simplicity with an accessible experience — for years, tools in this space felt too technical. But the value of e-signing has shifted. It's no longer just about the signature itself — it's about everything happening around it: tracking the status of signature requests, roles and permissions, expiration dates, signature sequences, placing multiple visual signatures, and more. We call these functions workflows, and they're built to help everyone at your company work more efficiently.

To keep the product usable and not overloaded with edge cases, we make decisions for the collective of our users — decisions that won't always fit every specific use case you run into. That's what the API is for: it gives you the freedom to build a customised interface or attach your own functions on top of ours.

Take a contract that needs two different signature standards. It's a rare case, and only a handful of customers run into it, so it isn't a function in our user interface. Today, you'd handle it manually in the UI: upload the document, invite the first signer with an advanced electronic signature (FES), download it, re-upload it, create a second signature invitation for a qualified electronic signature (QES), and download the final document with both signatures on it. With the API, you can automate that entire sequential flow — no manual steps in between. That kind of flexibility lets you handle far more complex processes, much more efficiently. Fabian will show you exactly that later in this webinar.

If it helps to have an image for it: think of the API as your own highly skilled personal assistant, one that never sleeps. It takes care of your files, answers e-mails, sets up meetings, and yes, it would even make you coffee if it could — except it does all of that in seconds and without a single coffee break. It's your own super-efficient, multitasking robot.

What's New in Skribble API v2

Waldemar Dick: I'm the CTO here at Skribble, and the API is one of my main responsibilities. We started with API version 1 six years ago, and it's come a long way. We switched internally to version 2 last year, and as of yesterday, it's publicly live. You'll find the documentation in Postman, including full Postman collections so you can try out everything we cover today straight away.

A few highlights: adding and removing signers is much simpler now. We introduced signing sequences and the ability to have multiple visual representations per real, encrypted signature. You can also switch ownership of a signature invitation — something the web application itself doesn't use, but that makes integration with third-party tools like contract management systems much easier. The API provides the document, and afterwards, a person can take over and adapt the flow directly in the web application.

We'll phase out version 1 eventually, but there's no urgency — the two versions are largely compatible, and you can run both side by side. The migration itself is minimal: change the base URL, rename one significant field, and ignore any deprecated or unfamiliar fields you don't need. Some customers already on version 2 completed their migration in one or two days.

We also have a second API: the document validation API. It has its own URL and a clean OpenAPI schema. It's public, and you can use it to validate documents you receive from third parties — or from Skribble — to check their legal standing. It'll eventually move into the main API, but for now, it's a standalone product using the same API keys.

Version 2 is more of a slight evolution than a revolution — we add features to it constantly, the same way we add features to the web application, which is itself just a regular user of this same public API. You could build the entire Skribble web app yourself on top of API v2. A few endpoints, like the signing process itself, stay protected for legal reasons, but they're open to anyone once we've confirmed you meet the legal requirements, like showing the signer the document and providing a signed copy afterwards.

What won't change is behaviour, unless legal or security requirements force it — which has almost never happened. What will change is the interface: new fields get added to the JSON responses as we roll out features. Our suggestion: don't build hard schema validation against our responses — just ignore fields you don't recognise yet. On the frequent request for an OpenAPI schema to auto-generate an SDK: we don't have one right now. We had one for version 1, but the inheritance we used to stay compatible during the v1-to-v2 migration conflicts with our schema generation tooling. We're considering building one manually, but it's not on the short-term roadmap.

One more honest note: our error messages got vaguer over time, and that's by design. Detailed error messages are a common source of information leakage, and they get flagged in our penetration tests if we reveal too much. That's not great news from a developer's perspective, but it is good news from a security perspective. If you get stuck, reach out — we can debug your integration and tell you exactly what happened on a personal level. Part of this is also our web application firewall, which screens every request before it reaches the API. If a document title looks like a SQL injection attempt, for example, it gets rejected — and you won't see much detail on why. Again, just get in touch if that happens.

The API keeps moving fast. Just yesterday, we released a new signature format compatible with 21 CFR Part 11 (US FDA). To stay in the loop: subscribe to our status page for release updates and maintenance windows, and check out our (fairly new) Google Group and mailing list for more individual-level discussion — you'll find the link in the show notes. If you have questions, you can also reach our engineers directly at public-api-users@skribble.com.

Case Study: How SBB Automates Signature Requests with Power Automate

Freddy Kaiser: Our API is the foundation for every integration we've built — with Microsoft, Google, SAP, and various specialised industry solutions. It works with any programming language, and also with no-code platforms, Zapier especially, which has over 7,000 out-of-the-box integrations you can combine with Skribble. Worth mentioning too: our API is public, which means AI tools can use it as well — ask ChatGPT or Copilot to generate integration code, and you'll get a solid starting point. On the no-code side, Microsoft has its own platform: Power Apps and Power Automate. Fabian from SBB will now walk you through a real use case built on exactly that.

Fabian Böhm: Thanks, Freddy, and hi everyone. I work at SBB, and I'm going to walk you through the use case we built with the Skribble API, using the Microsoft Power Platform — Power Apps and Power Automate. I'll introduce both frameworks, then go through our actual integration, and close with a short outlook on our next steps.

Our use case is process automation for auditing project portfolios. Before any infrastructure project gets built, our experts conduct large-scale portfolio audits, and at the end of that process, they need to sign the verification reports. Since these are highly skilled specialists, we want to minimise the administrative effort around that signing step. We're building a Power App that automates most of the documentation around the verification process, aiming to remove media discontinuity — switching between systems, printing, scanning — which used to cost our experts a lot of time. Power Automate flows run in the background of the app, handling routine admin tasks and database work. The Skribble API itself is accessed through a custom-built Power Automate flow.

Power Apps are web apps you access through your browser — just the graphical front end. In our case, it's a model-driven app: each row in the interface represents one audit portfolio. Experts click into an entry to see the audit's metadata, and once the audit is complete, that same entry has an interface that triggers the signature request, which calls the Skribble API in the background.

Behind that front end, Power Automate flows do the work. Power Automate is a visual, block-based programming framework, also accessible through your browser. Blocks run sequentially from top to bottom — conditions, loops, variables, HTTP requests, all built in and ready to use. There are also blocks for third-party tools: pulling data from Snowflake, or using advanced PDF functions from Adobe, for instance. These work like black boxes where you only adjust a few parameters, so you don't need much programming knowledge to build a flow. Flows can trigger on database changes, on a schedule (weekly, monthly, daily), or when waiting for a specific user interaction.

In our application, most fields are pre-filled since the data already lives in our database — who the signers are, the document title, a standard message to signers. The one thing our experts do manually is paste a link to the SharePoint PDF that needs to be signed, then confirm with a checkbox that everything is correct and that they're authorised to start the signature request — we have a fairly strict process defining who's allowed to trigger that. Once they press the button, the next thing that happens is entirely on Skribble's side: an e-mail invitation goes out to every signer involved in that audit. From there, they log in, verify their identity, and sign.

On our roadmap: we still have some final adjustments before going live in production — right now, the Skribble part of the app runs on our development server. We also want to automatically retrieve and process the signed document via the Skribble API callback once everyone has signed — download it, store it in our database, notify the relevant people. That's not implemented yet, but it's the plan. And because we're a large organisation with many teams, we'd really like to supervise how our API access is used in production, to make sure it's used the way we designed it and catch any misuse early.

Challenges, Security, and Lessons from SBB's Integration

Freddy Kaiser: What challenges did you run into building this integration, and how did you solve them?

Fabian Böhm: We were already using Skribble manually — everyone worked through the web interface. When we started building the integration, we began by sending requests through our browser's network console, which is very manual and takes a lot of effort. We then discovered Skribble's Postman collection, which sped things up massively: prepared HTTP requests for the different API commands made it easy to try things out. From there, it wasn't much of a challenge to get to what we wanted.

The bigger challenge was the callback function that notifies us once all signatures have been received. You need to provide a webhook — a URL Skribble calls once everyone has signed — but ours wasn't working, and we didn't get any detailed error messages. We reached out to our Skribble contact, and with their support, we quickly found the issue: the URL was simply misformatted.

Freddy Kaiser: We provide API credentials and keys to access the API — how do you keep those safe and secure on the Power Automate platform?

Fabian Böhm: That's something we're still actively discussing internally. The Power Platform gives users a lot of visibility — once someone is authorised to use an application, they can also see the flow's logs and its editing view. So we have to make sure secrets are never visible in the logs at any point during development. Power Automate has a ready-made block for Microsoft Azure Key Vault — you just plug it in and hide the block's inputs and outputs. For other vault providers, you'd likely need some custom flow work to integrate their secrets. On top of that, we have to stay compliant with our organisation's security guidelines before we're allowed to go live.

Freddy Kaiser: Anything the audience should know before they start building with Power Automate themselves?

Fabian Böhm: I'd invest time early on in thinking through who your users will be and how they'll access the application — and get your security team involved early. They likely already have preferred tools or processes for things like secret management, and those need to be factored into your development from the start. We started that conversation quite late, and we're still learning how much work sits behind what looks like "just" adding one block to a flow and pressing go.

Freddy Kaiser: Any feature requests for Skribble that would improve this kind of integration?

Fabian Böhm: Our application right now is a custom solution built from scratch — we use individual HTTP request blocks to talk to the Skribble API directly, which isn't very reusable. If another team wanted to integrate Skribble for a different use case, they'd have to adjust or copy our flow themselves. It would be great to have an official Power Automate block for Skribble — a black box where you just provide your input data and the block handles the rest. That would make this much more portable across teams. The other thing: server-side monitoring of API usage. From a security standpoint, and to understand how the integration is actually being used, it would help a lot to have that visibility from Skribble's side.

Freddy Kaiser: Both good points — the broader Microsoft Power Automate integration, including Vault support, is already on our radar. Stay tuned to future webinars on this. And thank you, Fabian, for a great presentation.

Getting Started with the Skribble API

David Fürsinger: You can create your own Skribble API keys directly in the product — you'll find them in the Skribble admin area, under "API keys." If you've blocked out time for this webinar, right after is a great moment to go create your keys and test things out. If you're already using the API or have questions while signing up, reach out to our Happy team at happy@skribble.com — they'll answer directly or loop in Freddy or Waldemar if needed.

We'd also love your feedback: there's a short survey for this webinar (scan the QR code, or find the link in the follow-up e-mail, which will also include the recording and a link to the API documentation).

Questions and Answers from the Webinar

Is Skribble already listed as an official connector in the Power Platform?

Freddy Kaiser: Not yet — that's part of our strategy to get listed.

Can I test the API during the 14-day free trial, and what if I need more time?

Waldemar Dick: If you sign up during our 14-day testing phase, you can create API keys at the demo level. Afterwards, you can create both production and demo keys in the admin section. If you need more time, just talk to us — we can extend the free trial.

David Fürsinger: You can also reach out about a monthly Pro Team plan, which costs around EUR 50 per month to extend by a month. We'll also show where to create API keys later in this session.

Did you secure the callbacks somehow?

Waldemar Dick: We recommend using a nonce — a number used only once — in the callback URL, so you can recognise it, though that's up to the integrator. On our side, if your endpoint supports mutual TLS, our callback sends a mutual TLS handshake, secured by certificate, so you can verify the request is genuinely coming from Skribble and no other source.

In the monitoring, how do you do that? Did you build your own dashboard?

Fabian Böhm: Monitoring is on our roadmap and our wish list, but we don't have server-side API monitoring yet — no dashboard or alerting in place at this point.

Do you plan to build an integration for the ERP system Odoo?

Freddy Kaiser: We're working with a partner called Braintech in this area — there's an Odoo Sign integration option. Best to reach out to me directly to discuss how to proceed.

Any experience with Business Central integration, workflow, or co-signing?

David Fürsinger: Nothing concrete to share right now — we'll have to follow up on this one.

Any integrations planned into Microsoft Word?

Freddy Kaiser: That's part of our broader Microsoft integration strategy. We're currently looking into an add-in option. Power Automate is the central platform here, connecting Word alongside Outlook, Excel, and Dynamics in one integrated way.

Is the webinar being recorded?

David Fürsinger: Yes, it is.

Is validation of the signature planned via API?

David Fürsinger: We already have a Skribble validation service today, and it's accessible through the API. If you're interested in validating signatures or documents — including ones not signed via Skribble — reach out to us at happy@skribble.com and we'll set up the necessary steps. Every document with digital signatures, across all existing standards, gets checked.

How do you handle it if a webhook notification doesn't arrive — for example, if the connection is down? Will it retry?

Waldemar Dick: Yes — the webhook doesn't just call once. It retries 10 times with exponential delay: after 5 seconds, then 10, 20, 30, and so on. We also just introduced a new endpoint where you can query what happened to your webhook and see the specific error, such as an unreachable IP, a failed HTTPS handshake, or a rejected URL.

The transcript ends here.

About the Speakers

David Fürsinger is Co-Founder and Chief Product Officer at Skribble, where he's worked since the company's founding in 2018. He previously worked at TaskFleet, HV Code, and ETH Zurich, and holds a background in neuroscience from ETH Zurich.

LinkedIn: https://www.linkedin.com/in/davidfuersinger/

Waldemar Dick is Co-Founder and CTO at Skribble, where he leads the API and product engineering, including API v2.

LinkedIn: https://www.linkedin.com/in/waldemar-dick-3bb7671b8/

Freddy Kaiser is Director of Strategic Initiatives at Skribble. He joined the company in October 2022 from Abacus, where he spent six years as Head of Engineering & Architecture, and previously worked at Swisscom, SwissSign, and Novell.

LinkedIn: https://www.linkedin.com/in/freddykaiser/

Fabian Böhm works at SBB (Swiss Federal Railways), where he built the Power Automate integration for the Skribble API to automate signature requests in the auditing of infrastructure project portfolios.