Integrating Guard.ch into your own tools
Guard.ch has one integration path: a launcher link that opens a live investigation in the person's browser. No SDK, no API key, no server work. This guide covers it end to end.
The surface is deliberately small. The browser extensions do not call an API; they build a single launcher link. This page documents exactly that surface, the same one our own integrations run on.
The result is always for a person to look at: hand off a link, and the investigation opens live in their own signed-in Guard.ch, with every request, cookie and redirect on the record.
How the hand-off works
- Your tool builds a link. A guard.ch/start link carries the address to investigate, encoded, and nothing else. Any language or platform that can build a URL can integrate.
- The person opens it. The investigation starts live in their own signed-in Guard.ch, in their browser. The browser extensions and the Outlook add-in use exactly this mechanism.
Before you start
- Launcher link
- guard.ch/start, opened like any URL; no keys, no SDK
- Sign-in
- Happens on guard.ch, in the person's own browser
- Plan
- The investigation runs on the account that opens it
No SDK or library is required. Any language or platform that can open a URL is enough.
Building a launcher link
The launcher lives at guard.ch/start. Opening it with a target hands over to the person's own browser: they sign in if needed, and on a paid plan the investigation starts and lands on the live view. Your tool holds no account, no token and no other Guard.ch state; the link is the entire integration.
Three query parameters, and only the first is required:
urlThe target. Our extensions wrap it in a small hex scheme: the prefix ENCODED- followed by the address as uppercase hex bytes, so the suspicious URL travels as an opaque token instead of a nested link. A plain URL-encoded value works as well.locationThe exit location for the investigation, as a country (us) or a specific city (us-dal). Omitted, Guard.ch chooses automatically.workspaceYour workspace's SSO slug. With it, a visitor who is not signed in yet is routed through your company's single sign-on instead of the generic sign-in form. It is a routing hint, never a credential: a wrong value simply falls back to the normal login.
A link without a language prefix redirects to the English launcher with the query preserved; build guard.ch/de/start if your team works in German.
Deploying to a fleet
To give every employee the interactive path without building anything, deploy the browser extensions: they are the launcher link with a right-click menu, toolbar popup and keyboard shortcut on top, and IT can push them company-wide. Managed installs read the workspace slug from browser enterprise policy (Chrome, Edge or Firefox), so every install routes staff through your single sign-on by itself.
The same slug is what you put into your own tools' launcher links, so a custom integration and the managed extensions sign people in identically. The integrations page lists everything prebuilt.
Limits and fair use
- The launcher link carries no entitlement. It is free to build and grants nothing by itself: whatever runs, runs on the person's own account, and a link forwarded to someone else simply meets their sign-in.
- One link, one investigation. Each opened link starts one live session in the person's browser. Hand off links as people need them rather than opening them in bulk from a script.
Security
- A launcher link contains no credentials and grants nothing; sign-in always happens on guard.ch, or through your own SSO.
- The address you hand off is the only thing that travels; nothing else about the context it came from is sent.
- Every request runs over HTTPS, and all Guard.ch data is stored within the EU under the same DPA as the rest of the product.
Next steps
Start with the launcher: wrap an address into a start link and open it. For anything this surface does not cover, contact us.