“Hey, we need a secure way to provide support.”
So… got an hour? That is the whole job: a Composer package, a config array, one call on plugins_loaded. The rest is our code, audited by Pritect and WPScan and 5 years into production.
What “secure” turns out to mean once you start building it
- A throwaway account on the customer’s site, scoped to the role you name
- An expiry that enforces itself, and revocation the customer controls
- Encryption before the login leaves their server, and the key handling behind it
- A record of who logged in, when, and whether it worked
- Brute-force checks on the endpoint you just opened
- An answer when a customer’s host asks how all of it works
Six things to build, then maintain in someone else’s WordPress for as long as your plugin ships. Or one composer require, and the answer to the host’s questions is a URL you send them.
Paste one prompt and your coding assistant does the integration
Hand Claude Code, Cursor or Copilot our AI Integration Prompt and your repo. It asks what it needs, installs the SDK, namespaces it, wires up the button, and ends with a checklist you can verify. Our docs are served as raw Markdown and llms.txt, so your assistant reads the source instead of guessing.
It is a shortcut, not a black box. The prompt runs the steps below, and you read every one in the diff before you accept it.
Wire it into the Composer and build step you already have
Run composer require trustedlogin/client, add Strauss or PHP-Scoper to your build so two plugins shipping TrustedLogin can never collide, load the namespaced autoloader, then instantiate on plugins_loaded:
$config = [
'auth' => [
'api_key' => '1234567890',
],
'vendor' => [
'namespace' => 'pro-block-builder',
'title' => 'Pro Block Builder',
'email' => 'support@example.com',
'website' => 'https://example.com',
'support_url' => 'https://help.example.com',
],
'role' => 'editor',
];One API key, your vendor details, the role you will ask for. Set the duration here too, from one day to one month; your customer sees exactly what you configured and approves it or does not. The installation guide covers the rest, and the example plugin is the finished result, running.
If anything goes wrong, it fails closed and your plugin keeps running
This code runs on sites you do not control, under your name, so the SDK holds itself to one rule: never crash the host site, always fail closed. Unreachable service, expired grant, missing capability, wrong key: access is refused and nothing else in your plugin notices.
Two plugins, one SDK
Namespacing in your build means your copy and the next vendor’s copy never meet. Skip it and they collide, which is why the install guide treats it as the step you cannot get wrong.
Hosts, caches and staging
Nginx turning a POST into a GET, a staging server on a production domain, an init hook that never fires on the front end: the troubleshooting guide names each one and the fix.
If we disappear
The SDK is GPLv2 in your repo and the Connector ships its source through WordPress.org. Neither stops working without us. Every failure mode is written down.
Your customer sees your plugin, not ours
The Grant Support Access screen renders inside your admin, so every part of it is yours to change. Filter the template HTML, replace the placeholders you do not want, style it to match. Hooks cover the rest of the flow, from the grant itself through revocation.
When the integration misbehaves, you get logs and a person
The SDK writes its own log on the customer’s site, and the dashboard records every grant and login attempt with what it did. On the Support plan, the founder answers integration email within one business day.
Read the source before you ship it
Client SDK docs
Architecture
The SDK needs an account to talk to. Free covers one customer site and five support logins a month, enough to build the integration and test it end to end.