Frends Integration
Frends can call TRUE as a step in any process you already run
If your organisation already runs Frends, you already have the piece that usually takes the longest. Frends builds processes that move data between systems, and TRUE is one more step in such a process: an HTTP call that issues a credential. The trigger can be anything Frends can already see, and the credential arrives branded as yours, on your own domain.
TL;DR
Frends is an integration platform, not a learning system. That makes it the right home for this when the event that means earned lives in an internal system nothing else can reach. You build the process in the Frends editor as you would any other: a trigger, the mapping, then an HTTP request to TRUE with the person's details. Because it is your own process, the rules can be as specific as your organisation needs, and the credential still carries your design and is written to blockchain at the moment of issue.
- Uses what you already run. If Frends is in your stack, TRUE is one more step in a process you already know how to build.
- Reaches internal systems. The trigger can be an event in a system nothing else can see, which is the case Frends exists for.
- Low code. The process is built in the Frends editor rather than written from scratch.
How does the Frends certificate integration work?
Frends already moves data between your systems. TRUE becomes the last step in one of those processes: when the process reaches the point that means somebody has earned a credential, it calls TRUE with their details, and TRUE issues and delivers the certificate.
1
Pick the trigger in your process
An incoming message, a schedule, or an event from an internal system. Frends can already reach the places a simpler tool cannot, which is the reason to use it here.
2
Add the call to TRUE
An HTTP request step with the recipient's details mapped from the process. Your TRUE token is held in Frends the way your other credentials are.
3
Credentials issue themselves
When the process runs, the person receives a branded, blockchain secured credential with a permanent verification link.
What does the credential carry?
The recipient name, what they earned, your organisation and the date it was issued, written to blockchain at the moment of issue so it cannot be edited or backdated afterwards.
- Recipient name and credential. Mapped from your own process, so the credential says what your systems say.
- Your organisation. The certificate is branded as yours and lives on your own domain.
- Date of issue, fixed. Written to blockchain at issuance, which is what makes backdating impossible.
- A permanent verification link. An employer confirms it by opening the link or scanning the QR code, without contacting you.
What has to be in place before it can be switched on?
A Frends environment, somebody who builds your processes, and a credential design. Nothing has to be installed, because the HTTP step is already part of Frends.
- A Frends environment and the team who maintains your processes.
- The event that means earned, which in a Frends setup usually lives in an internal system rather than a platform.
- A credential design, built by us to your profile or adapted by you from an existing template.
What does a recipient receive?
A branded, animated certificate delivered by email, on your own domain rather than ours. It carries a QR code and a permanent verification URL, so anyone can confirm it without contacting you, and it goes onto a LinkedIn profile in one click.
- Beautifully designed. Animated, branded and interactive rather than a static PDF.
- A shareable link. One URL that works in an email signature, a portfolio or a CV.
- QR code verification. An employer, a client or a regulator confirms the credential instantly.
- LinkedIn ready. Added to a profile in one click, which puts your name in front of their network.
- Blockchain secured. It cannot be edited, forged or backdated after issue.
How is personal data handled?
Only the fields your process maps into the call are sent, which for a credential is a name, an email address and what it is for. Because the process is yours, you can see and audit exactly what leaves your estate.
TRUE is hosted in the EU, and we sign a data processing agreement with you before anything is switched on.
How much has TRUE issued for organisations like yours?
More than 500,000 documents for over 200 organisations in 15 or more countries, and credentials shared by their recipients have produced over 100 million marketing impressions. These are TRUE platform figures, not third party research.
500K+ Documents issued
200+ Organisations
15+ Countries
100M+ Marketing impressions
Why put this in Frends rather than somewhere simpler?
Because of where the event lives. If the thing that means earned happens in a platform with its own webhook, use that. Frends earns its place when the event is inside a system that nothing else can reach.
| Capability | A platform webhook | A Frends process |
|---|---|---|
| Best when | The event is in a platform with its own outgoing call | The event is in an internal system |
| Who builds it | An administrator | Your integration team |
| Complex rules | Limited to what the platform offers | Whatever your process needs |
| Several source systems | One at a time | Combined in one process |
| Certificate itself | Identical | Identical |
What do integration teams ask about this?
Mostly whether anything has to be installed, how the token is held and when Frends is the right choice at all. Nothing, the way your others are, and when the event is internal.
Does anything have to be installed in Frends?
No. An HTTP request step is already part of the platform, so calling TRUE is one more step in a process you build the way you build every other.
Where does the API token live?
In Frends, held the way your other system credentials are. It does not belong in the process definition itself.
When is Frends the right place for this?
When the event that means earned lives in an internal system rather than a platform with its own outgoing call. If your platform has a webhook, use the webhook; it is less to maintain.
Can one process issue several credential types?
Yes. The process can choose the design from a field it already carries, so one process can serve several programmes.
Do recipients need a TRUE account?
No. The certificate arrives by email with a unique link. No login, no account and no app.
Can the certificate carry our own design?
Yes. We build the design to your graphic profile, or you adapt one from an existing template. The certificate is branded as yours and lives on your own domain.
Can we issue certificates for records that already closed?
Yes. Earlier records can be issued as a batch, so a backlog does not have to be handled by hand.
What does a recipient do with the certificate?
Share it. It is a link rather than a file, so it goes on a LinkedIn profile in one click and into an email signature or CV, and every share points back to a verification page carrying your name.
Ready to add the step?
We prepare your credential design and the exact call the process should make, your team adds the step, and the next run issues a verifiable credential.