The personalisation engine, as an API
Your app already knows who its members are. SharEarn turns one design into a finished, personalised card for each of them — and hands it back to you, inside your own product. Your users never leave your app.
Systems that already have members
If people log in to your product and you know their name, their photo and who they work for, you already have everything a personalised card needs. This is the part you do not have to build.
A CRM
Give every salesperson today's occasion card with their own name and number on it, from inside the CRM they already use.
A community platform
Chapters, federations and member bodies — one approved design, every member's card personalised, no design work asked of anyone.
A franchise or dealer portal
Head office publishes the artwork; each outlet shares it with its own branch details composed on.
A SaaS product
Add greetings, milestones and campaign creatives as a feature of your own app, without building a rendering pipeline.
Three steps from your database to a finished card
Pick a design
Choose the template you want to render — an occasion card, a greeting, a business promotion. The design decides which slots get filled and where they sit.
Post the member's details
One call carries the details you already hold: who the card is from, the brand it belongs to, and — on a card about someone — who it is about.
Get back a finished image
A composed card image and an attributed link come back. Show them in your app, attach them to a message, or hand them straight to the member to share.
One request: POST /v1/render
The details arrive with the request. Below is a fuller version of the example on the homepage — every slot the three namespaces define, filled in at once.
POST /v1/render
{
"template": "birthday-classic",
"brand": {
"name": "Lopez Realty",
"logo_url": "https://…/lopez-mark.png",
"chapter": "Bay Area",
"website": "https://lopezrealty.example",
"phone": "+1 415 xxx xxxx"
},
"personal": {
"name": "Maria Lopez",
"photo_url": "https://…/maria.jpg",
"position": "Principal Broker",
"contact": "+1 415 xxx xxxx"
},
"subject": {
"name": "Ayesha Khan",
"photo_url": "https://…/ayesha.jpg",
"message": "Many happy returns from all of us"
}
}
→ 200 · finished card image · attributed linkpersonal is the person sharing the card. subject is the person the card is about — a colleague's birthday, an award recipient, a new joiner. On a card that is only about the sharer, you send brand and personal and leave subject out.
Twelve keys, in three closed namespaces
That is the whole vocabulary. The namespaces are closed, so an unknown key is refused at submit — it is not quietly dropped and it does not render as a blank. If you send a key that is not on this list, the request comes back rejected, which is how you find a typo on your first test rather than on a thousand cards.
| Namespace | Key | Required | What it holds |
|---|---|---|---|
| brand | brand.name | Required | The organisation or business the card belongs to. |
| brand | brand.logo_url | Optional | The logo composed onto the card. |
| brand | brand.chapter | Optional | The branch, chapter or unit within the organisation. |
| brand | brand.website | Optional | The website shown on the card. |
| brand | brand.phone | Optional | The business number shown on the card. |
| personal | personal.name | Required | The person sharing the card. |
| personal | personal.photo_url | Optional | Their photo. Falls back to initials when it is missing. |
| personal | personal.position | Optional | Their designation or role. |
| personal | personal.contact | Optional | Their own number or contact line. |
| subject | subject.name | Required on subject cards | The person the card is about. |
| subject | subject.photo_url | Optional | Their photo. Falls back to initials when it is missing. |
| subject | subject.message | Optional | A short line addressed to them. Maximum 90 characters. |
Your key, your tenancy, and none of your users
A per-client key
Each integrating client authenticates with its own key. There is no shared key and no end-user login to arrange — your app calls us, your users do not.
Clients are isolated
One client's designs, calls and rendered output are not reachable from another's. Isolation is the boundary, not a setting you have to switch on.
We store nothing about your users
Member details arrive with the render call and are used to compose that card. SharEarn keeps no record of the people in your system — there is no profile of your users here to leak, export or reconcile.
This is usually the part that decides the integration. You are not handing a member database to a third party; you are sending the fields for one card, one call at a time.
A finished card, and a link that carries credit
Two things return from a render. The card image is composed and final — no client-side compositing, no font loading, no canvas work in your app. The attributed link travels with the card, so a share that came from your platform is still recognisable as such once it has left it.
Output today is image cards. Personalised video is coming; nothing else is promised beyond that.
Ask us for a key
There is no self-serve key issuance yet, so access is arranged by hand. Use the contact form on the organisations page — tell us what you are building and roughly how your members are structured, and we will take it from there.
Request API access See the plans →Per-client keys · client isolation · we store nothing about your users