The manual an issuing organisation actually reads

Issuing verifiable digital certificates and badges https://app.certlink.io

This manual is for the people who issue credentials — the administrator who registers the organisation, the designer who lays out the certificate, and the person who presses Issue.

If you are here because you received a credential, you need §13.2 and §13.5 only.

How to read it

Chapters 1–12 are in the order you will actually do them. If you are setting up for the first time, read them in order; each one ends where the next begins. Chapters 13–16 are reference.

Five things worth knowing before you start

1 · A credential cannot be edited. Once it is signed it has been downloaded, printed, emailed or added to a wallet. A mistake is corrected by revoking and re-issuing (§11.5), never by editing. This one rule explains most of the product's behaviour.

2 · Your workspace address is permanent. It is written into your issuer DID, which is inside every credential you sign (§2.3). Choose it as carefully as a domain name.

3 · Old signing keys are never deleted. They are the only thing that can verify what they signed (§6.3).

4 · Anyone who can issue needs two-step verification. And you cannot grant issuing rights to someone who has not enrolled — plan onboarding around it (§4.4).

5 · Nothing verifies until your organisation is approved. But you can build everything else while you wait (§2.5).

Getting help

The console carries Announcements and a Frequently asked questions section. For anything else, use the contact form at https://certlink.io/contact — and quote the error code if you have one (§16.11).

Everything in CertLink starts with a personal account. An organisation is registered from an account (Chapter 2), and every operator you later invite signs in with an account of their own.

One thing to know up front: issuers and recipients use the same kind of account. The sign-up screen says so — "Issuers and recipients use the same kind of account." You do not pick a role here. What you can do is decided later, by the organisation you create or are invited to.

1.1 Before you start

1.2 Two ways to sign up

Both create the same kind of account. You can add Google sign-in to an email account later, and you can add a password to a Google account later. Neither choice locks you in.

1.3 Sign up with email and password

Go to https://app.certlink.io/signup and fill in the form.

Then the agreements:

The Terms and the Privacy Policy open in a new tab, so you will not lose what you have typed. If you submit without the two required boxes, the form answers "Please accept the required agreements."

Press Create account.

Password rules

"Between 8 and 64 characters. It cannot contain your email or name."

A strength meter appears as you type — Not usable · Weak · Fair · Strong. It is guidance, not a gate; the four rules above are the gate.

Note — The Language field here is not the language of the certificates you will issue. Those are two different settings, and a third one is fixed onto each credential at the moment it is issued. Chapter 14 explains all three.

1.4 Verify your email

After Create account the screen changes to:

Verification email sent "Open the link in the email to finish verification. The link is valid for 24 hours and can be used once."

Until you verify, signing in is refused with "Your email is not verified yet." (E-AUTH-003). The sign-in screen offers resend the verification email right there, so you do not have to go back to sign-up.

If the mail has not arrived after a minute or two, check the spam folder before resending.

1.5 Sign up with Google

Press Continue with Google on either the sign-up or the sign-in screen, and pick your Google account. By continuing you accept the Terms of Service and the Privacy Policy — the screen states this next to the button.

Three things behave differently on this path:

An account created this way has no password. You can sign in with Google indefinitely, but if you also want to sign in with an email and password, open Account → Password. The screen is titled Set a password and explains why it is offered: "You signed up with Google, so this account has no password. Set one to sign in with your email as well." See §3.5.

1.6 Signing in

Go to https://app.certlink.io/login, enter your email and password, and press Sign in.

One option on this screen decides how long you stay signed in:

If your account has two-step verification turned on, the code screen comes next — that is Chapter 3.

1.7 When you cannot get in

About the lock

Repeated wrong passwords make each further attempt slower. Beyond that, only accounts that can issue credentials are locked outright: more than 10 failures locks the account for 30 minutes, and we send an email saying so. Ordinary accounts are slowed but not locked — a lock that anyone could trigger against any address would itself be a way to keep people out.

Forgot password

1. Forgot password on the sign-in screen.
2. Enter your address. The screen answers "If that address is registered, a reset link is on its way. Check your spam folder if it does not arrive." — the same answer either way, for the reason given above.
3. Open the link. It is valid for 30 minutes.
4. Set the new password. The screen warns first: "All sessions on every device will end after the reset."

A password reset does more than change the password. It ends every session on every device, and it clears every remembered browser on the account, so a browser that was skipping the two-step code will start asking for it again (§3.4). This is intended: if you are resetting because something went wrong, the reset has to be able to undo everything it left behind.

1.8 What comes next

You now have an account, but no organisation — so there is nothing to issue from yet. Signing in takes you to a screen that asks you to create one.

→ Chapter 2 · Registering your organisation and getting approved

An account is a person. An organisation — called a workspace in the console — is the issuer whose name appears on every credential you produce. You cannot issue anything until you have one and it has been approved.

One workspace is one issuing body. If your institution issues under two distinct brands that recipients would recognise as separate issuers, register two workspaces. The person who creates a workspace automatically becomes its Owner.

2.1 Opening the form

Sign in and you are taken to the workspace list. If you have none, the console asks you to create one. From inside an existing console you will find + New workspace in the organisation switcher at the top of the sidebar.

The screen is titled Create a workspace: "Register as an issuer. You can issue credentials once the review is approved."

2.2 Organisation

2.3 The workspace address cannot be changed

Workspace address is the short identifier in your console URL — app.certlink.io/console/vtex.

⚠️ Why this one is permanent. The workspace address becomes part of your issuer's DID — the identifier that is written inside every credential you sign, and that any external verifier resolves to check your signature. Credentials already in recipients' hands cannot be rewritten. Changing the address would break the verification of everything you have ever issued.

Take a moment over it. Use the name your recipients would recognise, not a project code.

2.4 Contact and formats

On the time zone. This is not a display preference. Issue dates, expiry dates and the point at which a daily or monthly credential-number counter resets are all computed in it, and the date printed on a credential is frozen using the setting that was in force at the time of issue. Set it to the zone your organisation actually operates in, and then leave it alone.

Press Submit for review.

2.5 While the review runs

Your workspace opens immediately, with a status badge at the top of the dashboard.

The dashboard shows: Review in progress (within 3 business days) — "While the review is pending you can still create designs and credential definitions, but issuing stays blocked. (E-ORG-001)"

So the waiting time is not dead time. You can do most of Part 2 now:

When approval comes through, the issuer DID and your first signing key are generated automatically — you do not have to ask for them. Chapter 6 explains what they are and the one rule you must never break with them.

2.6 What you can change later, and what you cannot

The pattern behind this table is worth internalising, because it repeats throughout the product: anything that has been signed into a credential and handed to someone cannot be edited. It can only be superseded by a new issue. Settings that only affect future issues are freely editable; settings that are baked into past ones are not.

2.7 Working in more than one organisation

One account can belong to several organisations, with a different role in each. The switcher at the top of the sidebar (Switch organisation) moves between them, and + New workspace starts another registration.

Your permissions are per organisation. Being an Owner in one says nothing about what you can do in another.

2.8 What comes next

Before you can issue — and, for many of you, before the console will even show you the Issue button — your account needs two-step verification.

→ Chapter 3 · Securing your account

Issuing a credential is not an ordinary write. A signed credential and a printed certificate are already in someone's hands the moment they go out, and they cannot be recalled — only revoked. That is why the accounts able to do it are held to a higher standard than the rest.

This chapter covers two-step verification, remembered browsers, and your password.

3.1 Who has to turn it on

Two-step verification is mandatory for the Owner of an organisation and for anyone who can issue credentials. Until they enrol, those accounts can sign in and look around, but the console blocks the actions that matter:

Two-step verification is required. "This account can issue credentials, so issuing and revoking stay blocked until you enrol." [ Enrol now ]

The security screen says the same thing: "This account can issue credentials, so two-step verification is mandatory. Issuing and revoking stay blocked until you enrol."

For everyone else it is optional and still recommended: "Even if your password leaks, no one can sign in without your authenticator app."

For Owners and Administrators — this also works in the other direction. You cannot grant someone issuing permission until their account has two-step verification on. Chapter 4 covers what that means for onboarding a new colleague.

3.2 Turning it on

Go to Account → Security and press Turn on two-step verification.

1. "In your authenticator app (Google Authenticator, 1Password, …) choose 'Scan QR code'."
2. "Scan the QR code below, or type the secret in by hand if scanning is not possible."
3. "Enter the 6-digit code shown in the app."

Press Verify and turn on. The screen confirms Two-step verification is now on, and — if your account required it — "You can now issue and revoke credentials."

Any standard TOTP authenticator works. The QR code is labelled with your email address so you can tell it apart from other entries in the app.

3.3 Backup codes — read this part

Immediately after enrolment you are shown 10 backup codes, each in the form A1B2C-3D4E5.

"These backup codes are shown only once. They are the only way back in if you lose your authenticator. Keep them somewhere safe."

Save them before you tick I have saved the backup codes somewhere safe. A password manager or a sealed printout in a safe are both fine; a screenshot in your photo library is not.

If you lose the authenticator and the backup codes, you cannot recover the account yourself — contact CertLink support, who can reset the second factor after verifying who you are.

3.4 When you will be asked for a code

Two different questions are being asked, and they have different answers.

Signing in asks "is this the right person?" — you enter a code once per sign-in.

Sensitive actions ask "is that person still the one sitting here right now?" — these require a recent verification even in an active session:

Remembering a browser widens that window; it does not remove it. Twelve hours is also the length of an ordinary console session, so nothing is gained by making it longer.

3.5 Remembered browsers

When you enter a code you can tick Remember this browser for 30 days.

"On a remembered browser we will not ask for a code again for 12 hours. Do not tick this on a shared computer."

Manage them under Account → Security → Remembered browsers, where the one you are using now is labelled This browser, each entry shows when it was last used, and you can Revoke one or Revoke all.

What a remembered browser is not. It is not a way in. On its own it authenticates nothing — without a live session and your password it does nothing at all. It only affects how often you are asked to re-confirm. That is why leaving one on a shared machine is untidy rather than catastrophic — but tidy is better, so do not tick it there.

3.6 Turning it off

Account → Security → Turn off, confirmed with your password.

If your account can issue credentials, the button is refused: "Accounts that can issue credentials cannot turn off two-step verification. Adjust the permissions first." The permission comes first and the second factor follows it, never the other way round.

3.7 Your password

Changing it

Account → Password → Change password, entering your current password and the new one twice.

"Changing it signs out every other device and clears every remembered browser. This browser stays signed in."

The new password must meet the same four rules as at sign-up (§1.3), and it cannot be the one you are already using — "That is the password you are already using."

Setting one for the first time

If you signed up with Google you have no password. Account → Password then shows Set a password: "You signed up with Google, so this account has no password. Set one to sign in with your email as well."

Setting one does not remove Google sign-in. Afterwards both routes work.

3.8 Your profile

Account → Profile holds the rest of your personal settings.

Changing the language reloads the page in the new one. Note that this is your language, not your organisation's issuing language and not the language printed on a credential — Chapter 14 sets the three side by side.

3.9 What comes next

Your account is ready and your organisation is registered. From here on the work is the organisation's: who else gets in, and what you have to build before the first credential can go out.

→ Chapter 4 · Operators and permissions

Most organisations do not issue with one person. The designer who lays out the certificate, the administrator who runs the programme, and the person who presses Issue are often three different people — and they should not all have the same access.

Settings → Team is where that is decided.

4.1 The six roles

The full 6 × 14 grid is in Appendix B. The shape of it is worth knowing now:

Two things to notice. An Issuer can issue but not revoke — undoing an issue is a heavier act than making one, and it sits with Administrators and the Owner. And billing and signing keys belong to the Owner alone; not even an Administrator can touch the keys that sign your credentials.

Menus you do not have permission for are hidden, not greyed out. If a colleague says a menu is missing rather than disabled, that is the permission system working as designed — check their role rather than looking for a bug.

4.2 Inviting someone

Settings → Team → Invite a teammate. Enter the email address, choose the role, press Invite.

"Invitation sent. It expires in 7 days."

The invitation goes to that address as an email. The person opening it needs a CertLink account:

An invitation is tied to one email address. If a colleague's address changes, send a new invitation rather than forwarding the old mail.

4.3 The team list

Team ({count}) shows everyone, with:

4.4 Two rules the screen enforces

Both are printed under the list, and both will stop you at some point.

At least one Owner must remain

"· At least one owner must remain. (E-ORG-005)"

You cannot demote or remove the last Owner. To hand the organisation over, promote the new Owner first, then step down.

Keep two Owners. An organisation with a single Owner has a single point of failure for everything only an Owner can do — billing and signing keys included. Promoting a second, trusted Owner costs nothing and removes that risk.

Issuing rights require two-step verification

"· To grant issuing rights (Issuer and above) the target account must have two-step verification enrolled."

This is the constraint that most often surprises people onboarding a new colleague, so plan around it:

1. Invite them as a Member (or with any non-issuing role).
2. They accept, sign in, and turn on two-step verification (§3.2).
3. Then you can change their role to Issuer, Administrator or Owner.

Trying to do it in the other order simply fails, and the failure is not a bug. The same rule runs in reverse: an account that can issue cannot turn two-step verification off until its permissions are reduced first.

4.5 Choosing roles well

Give Designer to anyone whose job is the artwork. It is the only role that touches designs without seeing a single recipient's name, which makes it the right answer for outside help.

4.6 What comes next

The team is in place. Now for the four things that must exist before a credential can be issued.

→ Chapter 5 · What has to be ready before you issue

Issuing is the last step, not the first. Four things have to exist, and they have to exist in order, because each one is built on the previous.

Your dashboard tracks exactly this, under Getting started:

Each step shows Done or Not done, so the dashboard is the answer to "what is stopping me from issuing?" at any moment.

5.1 The order, and why it is that order

Approval  ──►  Signing key + DID        (Chapter 6, automatic)
                     │
Custom attributes ───┤                  (Chapter 7 — before designs)
                     ▼
                  Design                (Chapter 8)
                     │
                     ▼
          Credential definition         (Chapter 9 — connects the design)
                     │
                     ▼
                   Issue                (Chapter 10)

Custom attributes come before designs. Only attributes that already exist can be placed on a design — the editor refuses the rest: "Attributes that are not defined cannot be placed." If you lay out a certificate first and then discover you need a field for a score or a course code, you have to go back, define it, and return to the editor. Ten minutes in Chapter 7 saves that.

The design comes before the definition, because the definition is where you connect one. A definition can be saved without a design, but then nothing renders — no PNG, no PDF, no image at all — and the issue screen will warn you.

5.2 The blocking conditions

These four are the ones that actually stop an issue. Each has an error code you can quote when asking for help:

A fifth one bites later rather than at the start: an attribute placed on the design with no value stops that row with "Some attributes placed on the design have no value." (E-CRD-004). That is deliberate — a blank line on a printed certificate is never noticed until it is in someone's hands.

5.3 A test issue is part of the checklist

Step 5 is Test issue (one to yourself) — one credential, to your own email address, before the real batch.

Do it. It is the only way to see the four things that only appear at issue time: the rendered certificate as the server actually produces it, the notification email as your recipients will receive it, the claim page, and the public verification page. Every one of those is downstream of choices you made in Chapters 7–9, and none of them is visible from the editor.

Then revoke it (Chapter 11), which also teaches you what revocation looks like from the outside.

5.4 What comes next

→ Chapter 6 · Issuer identity: DID, signing keys and status lists

Settings → Issuer identity

This is the machinery that makes a CertLink credential verifiable by someone who has never heard of you. It is created for you and mostly runs itself. Read this chapter anyway — it contains one rule that, if broken, invalidates every credential you have ever issued.

6.1 It is created automatically

Before approval the screen reads:

Issuer identity has not been created yet "The DID and signing key are created automatically once the workspace passes review."

You do not request them. When your organisation is approved, the DID is published and the first signing key generated.

6.2 Your DID

A DID is a public identifier for your organisation, of the form did:web:…:org:{slug} — which is why the workspace address you chose in Chapter 2 can never change.

Every credential you issue carries this identifier. A verifier anywhere in the world resolves it, finds your public keys, and checks the signature. No account and no contact with us is required.

The screen notes one property that matters more than it looks:

"The DID Document is a public, unauthenticated path. It keeps answering even if the organisation is suspended, so verification of existing credentials never stops."

Whatever happens to your account with us, credentials already in people's hands stay verifiable. That is the promise the whole product rests on.

6.3 Signing keys

The Signing keys table lists each key with its Key ID, Algorithm, number of Signatures, and when it was Created.

Three rules are printed under the table:

"· Private keys are never shown and cannot be exported." "· Old keys stay in the DID Document. Removing one makes every credential it ever signed fail verification." "· We recommend rotating once a year."

The one rule that matters

⚠️ An old key is not clutter. It is the only thing that can verify what it signed.

A signed credential cannot be re-signed — it is already printed, already emailed, already in a wallet. If the key that signed it disappears from your DID Document, every one of those credentials starts failing verification, and there is no way to repair them. Retired keys therefore stay published forever, which is exactly why the table distinguishes "kept for verification" from Revoked.

Rotating

Rotate key creates a new active key; the previous one moves to Rotating and keeps verifying its own credentials. Nothing already issued is affected. Once a year is the recommendation.

Revoking

Revoke key is not routine maintenance — it is what you do if a key is believed compromised. The confirmation makes you type the key ID:

"This affects verification of every credential signed with this key. Type the key ID '{kid}' to continue."

Managing keys requires the Owner role and a recent two-step verification (§3.4).

6.4 Status lists

Below the keys sit the Status lists (Bitstring Status List).

"Created automatically on the first issue. They roll over every 131,072 slots."

There are always two, and the table shows the Purpose, Slots used and Last published for each:

They are separate on purpose. A single shared list would mean that lifting a suspension also lifts a revocation — which is not a distinction you want a bug to erase.

Every credential points at both lists from the moment it is issued, and the lists are published automatically. There is nothing here for you to operate; the screen exists so you can see it working.

6.5 What comes next

→ Chapter 7 · Custom attributes

An attribute is a field whose value differs from one recipient to the next — a name, a score, a course code. The design is a layout; the attributes are what gets poured into it.

"Define the fields your issue data can carry. Only attributes defined here can be placed on a design or used as an upload column."

That sentence is the reason this chapter comes before Chapter 8. Everything you want on the certificate, and every column you want in your spreadsheet, has to exist here first.

7.1 Built-in attributes

Every organisation gets these. Built-in attributes "are provided to every organisation. They cannot be edited or deleted."

The key is what you actually work with — it is what appears in the editor's attribute list and what you write inside body text as [recipient.name].

Notice that the three recipient fields are masked by default and the rest are not. That is the right default: a certificate's content is public information, while the person on it is not.

7.2 Adding your own

Add attribute opens New custom attribute.

"No custom attributes yet. Add the fields only your organisation uses — a score, a course code, and so on."

7.3 The key and the type are permanent

"The key and type cannot be changed. Issue data and designs already point at this key, and changing it would break those links silently."

Silently is the important word. Nothing errors; the design simply stops finding its value, and you discover it on a printed certificate. Decide the key and the type once.

If an attribute is no longer wanted, you Deactivate it rather than deleting it — and if it is already in use the console does that for you: "It is in use, so it was deactivated instead of deleted." Deactivated attributes show as (inactive) and can be brought back with Reactivate. Past credentials keep their values either way.

7.4 Required when issuing

"Issuing is blocked when it is empty — better that than a blank certificate going out."

Mark an attribute required and a row with no value stops rather than proceeding. In a spreadsheet of 300 people the missing cell is flagged in the validation report (§10.5) with the row number, before anything is signed.

This is a deliberate trade: a stopped batch is an inconvenience, a printed certificate with a blank line is an embarrassment you cannot recall.

7.5 Masking

Mask on the public verification page — "This is the default. Turn it off and the value is visible to anyone."

The public verification page is reachable by anyone holding the link or scanning the QR code. It is meant to answer "is this credential real?", not "who received it and what was their score?".

Leave masking on unless you have a specific reason and the recipient's agreement. The column in the attribute list reads Masked or Fully visible, so you can audit the whole set at a glance.

Chapter 9 sets the default for a whole credential definition (§9.6), and the recipient can share a full-detail view themselves. Masking here is the floor, not a limit on what they can choose to show.

7.6 What comes next

→ Chapter 8 · Designing the certificate

"Lay out the certificate, then connect it to a credential definition."

A design is a layout, saved independently of any particular credential. One design can serve several definitions, and a definition without a design issues no image at all.

8.1 Starting a design

New design asks for two things.

Starting point — a template, or Blank canvas ("Start from nothing and build it yourself."). Templates can be searched and filtered by All / Certificates / Badges.

Size:

Badges are square, so there is no orientation to choose — the option disappears. A badge is not a document; it is an image that sits in a wallet, on LinkedIn, or in a profile, and it will often be displayed small. Leave generous margins.

Choose the size now. Applying a template later changes the canvas: "Applying this changes the canvas to {paper} {orientation}." and "Applying a template replaces what is on the canvas."

8.2 The editor

Three columns: tools on the left, the canvas in the middle, properties and layers on the right.

Left panel tabs:

Canvas navigation: "Ctrl + wheel to zoom · Space + drag to pan". Undo is Ctrl+Z, Redo is Ctrl+Shift+Z, Group is Ctrl+G.

8.3 Attributes — the part that makes it a certificate

Static text is the same on every copy. Attributes are what differ per recipient: "Replaced with real values when issued."

Two ways to use them:

1. Place one as its own element — drag it from the Attributes tab onto the canvas.
2. Mix them into body text — "You can mix attributes into body text, like [recipient.name]." So a paragraph reading This is to certify that [recipient.name] completed [achievement.name] resolves per recipient.

While editing, an attribute shows its Sample value (§7.2), which is why setting samples is worth the seconds it takes.

"Attributes that are not defined cannot be placed." If something you need is missing, define it under Settings → Custom attributes and come back.

The editor warns before you get burned:

⚠️ "Undefined attributes: {names} — they will have no value at issue time. Define them first under Settings › Custom attributes."

Do not save over that warning. An attribute with no value stops the issue with E-CRD-004, and in the best case you find out during the validation report rather than after printing.

8.4 The verification QR code

Add verification QR code places the QR that makes a printed certificate checkable.

"Each credential's verification URL goes in automatically at issue time. Scanning the printed QR opens the public verification page."

Each credential gets its own. You place the box; the content is generated per credential.

Put one on every printed certificate. A paper certificate with no QR is a piece of paper. The QR is the entire difference between a document someone has to trust and one they can check.

8.5 Text that does not break

Names vary in length far more than layouts allow for, so every text element has an Overflow behaviour — "Keeps long names from breaking the layout."

Combine it with Fixed width (wraps or shrinks). Test with the longest name you realistically expect, not a short one.

Fonts

"Only fonts installed on the render server can be chosen."

If a font is missing you are warned: "Fonts not installed on the server: {names} — credentials will render with a fallback font." Never ignore this — the rendered output will not look like your canvas.

Images

"PNG, JPG or SVG up to 2 MB. Scripts are stripped from SVGs before saving."

Add images to the canvas, or set one as a Background image covering the whole canvas.

8.6 Preview — the only output that counts

Preview renders the design the way the server will actually produce it.

"The editing canvas is an approximation; this image is what actually gets issued." Server-rendered preview — "Identical to what is issued"

The editing canvas is a fast, interactive approximation. Fonts, text fitting and spacing can differ slightly. Check the preview before you connect a design to a definition, and check it again after any change to fonts or text sizing.

8.7 Saving and revisions

Designs save automatically (Auto-saved), and Save confirms with Saved · revision v{seq}. Unsaved changes shows when something is pending.

Each save creates a revision. Two consequences:

• The design list shows Unconfirmed for a design whose latest revision has not been confirmed.
• Every issued credential is pinned to the exact revision it was issued from. Editing a design never changes a certificate that already exists — re-rendering it years later reproduces the original.

So you can keep improving a design without disturbing anything already issued. What you cannot do is retroactively fix a certificate by editing the design; that requires revoking and re-issuing (§11.4).

8.8 What comes next

→ Chapter 9 · Defining a credential

"The reusable master design for a certificate or badge. Every issue is based on one of these."

A definition is the thing itself — what the credential means, who qualifies for it, how long it lasts, how it is numbered, and which design it prints on. You create one per programme, not one per person.

Before you start. "Criteria and type cannot be changed after the first issue, so take care filling these in." The rest of this chapter explains what that costs you if you rush.

9.1 The form

New definition opens a four-step form. The step indicator reads {current} of {total} · {name}.

9.2 Step 1 — Basics

Standard vocabulary

"This goes straight into the credential's achievementType. It cannot be changed after issuing."

This is the single field that tells the outside world what kind of thing your credential is. A wallet, a university admissions system or an employer's HR platform reads it. Choosing "course completion" for something that is actually a licence misrepresents it to every system that ever reads it — and it cannot be corrected afterwards.

9.3 Step 2 — Details

Criteria is not a marketing description

Criteria answers "what did this person actually do?". It is the field a sceptical reader looks at, and it is one of the two fields that lock after the first issue. Write it as if it will be read by someone deciding whether to believe the credential — because it will be.

Framework alignment

"Link to an external competency framework. It rides in the standard alignment so other institutions' systems can read what this credential means."

Add alignment, then fill in Target name, Target URL, Framework name, Classification code and Target type. Optional, and worth doing if your sector has a framework — it is what lets another institution's system understand your credential without a human reading it.

9.4 Step 3 — Expiry

Use Relative to issue date for anything issued continuously; use Fixed date when a whole cohort expires together. An expiry date earlier than the issue date is refused (E-CRD-007).

9.5 Step 3 — Credential numbers

The Credential number rule builds the serial printed on each credential, from tokens:

"Tokens: {YYYY} {YY} {MM} {DD} {YYMMDD} {####} {ORG}"

So EHRD-{YYMMDD}-{####} produces EHRD-260817-0001.

A live Preview (in {timezone}) shows the result. The time zone is your organisation's (§2.4) — that is what decides when "today" rolls over for a daily reset.

Match your existing numbering if you have one. Credential numbers end up in registries, spreadsheets and HR systems. Getting the format right on the first definition is much easier than reconciling two schemes later.

9.6 Step 3 — Visibility and notification

Default recipient visibility controls what the public verification page shows. Masked means a name appears as J*** S**** to anyone with the link. Leave it masked unless the credential is meant to be a public roll of honour and the recipients know it.

Search engine indexing is a bigger decision than it looks: turning it on can make a person's credential findable by name in a search engine, permanently. Off is the right default.

9.7 Step 4 — Design and status

"Every attribute placed on the chosen design must already be defined before this can be saved."

If saving fails here, the design references an attribute that no longer exists — go back to Chapter 7 or Chapter 8 and reconcile them.

A definition with Not connected can still issue, but produces no images at all. The issue screen warns: No design — no image or PDF will be produced.

Status is the switch that makes a definition available on the issue screen. Leave it Draft while you are still working.

9.8 The four statuses

A definition can only be deleted while nothing has been issued from it — "Delete the '{name}' definition? It can only be deleted if nothing was issued from it." (E-CRD-002). Once it is In use, Archive is how you retire it.

9.9 What locks after the first issue

Credentials have already been issued from this definition "Criteria and type can no longer be changed — if they diverged from what was already issued, the credentials would stop meaning what they say. Create a new definition instead."

The dividing line is the same one from Chapter 2: what a credential asserts cannot be rewritten once it has been signed and sent. If the meaning of a programme genuinely changes, that is a new definition, not an edit — and having both is the honest record.

9.10 What comes next

Everything is in place. Part 3 is the issue itself.

→ Chapter 10 · Issuing credentials

"Issuing is hard to undo. Check the summary before you run it."

That warning is on the screen for a reason. A credential that has been issued is signed, rendered, stored and — if you asked for it — emailed. None of that can be taken back. A mistake is corrected by revoking and re-issuing (Chapter 11), never by editing.

This chapter is the one to read slowly the first time.

10.1 Before the screen will let you in

10.2 Choosing what to issue

Under What to issue, pick a Credential definition. The screen then tells you what that definition will actually do, as a row of labels:

Read that row every time. It is the cheapest possible check that you selected the definition you meant to.

Then choose the mode:

10.3 One at a time

Recipient

Below that, Custom attributes — every attribute the definition needs (Chapter 7). Anything marked required must be filled in, or the issue is refused rather than producing a certificate with a gap in it.

Issue settings

On backdating. Issuing a certificate for a course that finished last month is legitimate, and the issue date is what the certificate will say. Future dates are refused — a credential cannot claim to have been issued at a time that has not happened.

On typing a credential number yourself. Leave it blank unless you are reproducing a number from an existing register. The automatic sequence cannot collide; a hand-typed one can (E-CRD-010).

Press Issue now.

10.4 Bulk upload — step 1, the template

"Download the template — its columns match this credential definition — fill it in, then upload it."

Download upload template (.xlsx) produces a spreadsheet whose columns are generated for this definition. Always download it fresh rather than reusing an old file — if the definition's attributes have changed, the columns have changed with them.

Columns the definition does not know about are not an error; they are dropped:

Some columns are not defined — "{columns} — these columns are ignored. Define them as custom attributes in settings first if you need them."

Read that message when it appears. A column that is silently ignored is exactly how a score or a course code goes missing from 300 certificates.

10.5 Bulk upload — step 2, the validation report

Nothing is issued yet. The report classifies every row:

Problems are listed with Row, Name, Column and Reason, so you can fix the spreadsheet and upload it again with Cancel and upload again.

If the file is larger than your remaining quota:

This exceeds your remaining quota (E-CRD-012) — "{rows} to issue · {remaining} left in quota"

Errors are skipped, not fixed. You can proceed with errors present, and those rows simply do not get issued. That is often what you want for a few bad email addresses — but it means the batch you thought covered 300 people covered 287. The final summary tells you how many were excluded; read it.

10.6 Bulk upload — step 3, the final check

Final check before issuing summarises what is about to happen:

Two confirmations are required:

1. Tick I have checked the above.
2. Type the number of recipients — "Enter {count}."

Then Issue {count}, skipping rows with errors.

Why you have to type the number. A checkbox can be clicked without being read. Typing the count forces you to have looked at it — and the number is the one thing that catches the most expensive mistake, which is issuing to the wrong file. If the figure surprises you, stop.

10.7 While it runs

Issuing — {done} of {total} "The job keeps running if you close this page. Results appear in the issue history when it finishes."

The page streams progress live (Live). If the connection drops it says so — "(live updates disconnected — use refresh below)" — which affects the display only, never the job.

The Processing log shows each row as Issued or Failed, with a Progress bar and Total / Succeeded / Failed counts.

Issuing takes real time. Each credential is assembled, signed, rendered into several images and a PDF, written to the ledger and queued for email. Tens of seconds per credential under load is normal — close the page and come back.

10.8 When it finishes

⚠️ "Anything already signed and stored is not rolled back. Revoke what was issued in error."

A partly failed batch is not undone. The successful rows are real credentials — signed, stored, possibly already emailed. There is no "cancel the batch" button, and there could not be one.

Failed rows ({count}) lists what did not go through, with an Attempts count. Retry the failures re-queues only those — "{count} queued for retry" — leaving successful rows untouched. Most failures are transient; ones that persist usually point at missing attribute values or a malformed email address.

From here, View issue history or Issue more.

If you submit twice

This request was already accepted — "The same request is already done or in progress. Nothing was issued twice."

Double-clicking, or resubmitting after a browser reload, does not double-issue. This is guaranteed, not best-effort.

10.9 What comes next

→ Chapter 11 · After issuing

"{count} credentials issued. Recipient details are shown masked."

Everything you have issued lives here — what state it is in, whether the recipient collected it, whether the notification arrived, and how much it has been looked at. It is also where mistakes get corrected.

Note the masking: recipient details are masked in your own console too. Seeing a full list of names is a separate permission (export), and the default view does not need it.

11.1 Finding a credential

Unclaimed only is the useful one for follow-up: those are people whose credential was issued but who have not opened it yet.

11.2 The five states

11.3 Resending the notification

Resend sends the notification email again, and the button confirms with Resent.

Use it when the column shows Send failed, or when a recipient says nothing arrived. Check the address first — resending to the same wrong address will fail the same way. A wrong address cannot be edited on an issued credential; that needs a revoke and re-issue.

11.4 Revoking and suspending

Revoke opens Revoke credential, which states the stakes before anything else:

"Permanent revocation cannot be undone. If you revoke by mistake you must re-issue under a new UUID. The verification page switches to 'Revoked' immediately and downloads and sharing are blocked."

Choose the type

When in doubt, suspend. Suspension answers the same question to a verifier — this credential is not currently valid — and it can be lifted with Unsuspend. Revocation cannot. The two use separate mechanisms internally (§6.4) precisely so that lifting one never touches the other.

Record why

Write the details as if someone will read them in two years without you in the room — because that is what an audit log is for.

Show the reason on the verification page is off by default, and should usually stay off. "This credential was revoked" is a fact about the credential; "revoked because the holder was found to have falsified attendance" is a statement about a person, published to anyone with the link. Turn it on only when the reason is neutral — a re-issue after an administrative error, say.

Confirm

Confirm — "To continue, type '{name}' exactly."

Then Revoke. The public verification page changes immediately, and downloads and sharing stop.

A credential that is already revoked cannot be revoked again (E-CRD-006).

11.5 Correcting a mistake

There is one procedure, and it is the same for a misspelt name, a wrong date and a wrong recipient:

1. Revoke the credential, reason Issuing error, with the details recorded.
2. Issue a new one with the correct data (Chapter 10).

The new credential has a new identifier. The old one stays in the history as revoked — the record shows what happened rather than pretending it did not.

Why there is no edit button. The credential has been signed, and it has already been downloaded, printed, emailed or added to a wallet. Editing the copy in our database would leave the copy in the recipient's hands saying something different — and the one in their hands is the one a verifier is holding. A record that can be quietly changed after the fact is worth nothing, which is the whole point of the product.

11.6 What the recipient sees

Verify on each row opens the public verification page exactly as an outsider sees it. Use it after your test issue (§5.3) — it is the fastest way to check that masking, the design and the issuer details all look the way you intended. Chapter 13 covers that page in full.

11.7 What comes next

→ Chapter 12 · Organisation settings

Four tabs:

Everything here needs the settings permission — Owner or Administrator (§4.1).

12.1 Basics

On renaming. Credentials issued before the change keep the old name, permanently. This is correct, not a limitation: a certificate should say who issued it at the time. If your organisation has been renamed, the historical record showing the former name is the accurate one.

On changing the domain. It puts your organisation back into review. Expect the badge to return to Under review and issuing to pause (E-ORG-001), so do not do it the week you have a graduation batch to run.

12.2 Issuer branding

The logo rule is the same rule as everywhere else: it changes the future, not the past. Images already rendered are not regenerated, because they are already in recipients' hands. If a rebrand must reach existing credentials, that is a revoke-and-re-issue decision (§11.5), not a settings change.

The LinkedIn organisation ID is worth setting. It is the difference between a recipient adding your credential to their LinkedIn profile attributed to your organisation, and not being offered the option at all.

12.3 Contact and formats

The time zone is not a display setting. It decides issue and expiry dates and when a daily or monthly credential number resets (§9.5). Because each credential freezes the setting in force when it was issued, changing it now can leave new credentials out of step with old ones. Set it once, at registration, and leave it.

Issuing language

"The default language for issued credentials and notification emails. A recipient's own language setting wins over it. The console language is chosen per person in account settings."

Three different languages are in play, and confusing them is the most common misunderstanding in the product:

And a fourth thing that is not a setting at all: the language already printed on an issued credential. It is fixed at the moment of issue and cannot be changed afterwards — same rule as the design revision and the issuer name. Chapter 14 lays all of this out.

12.4 What can be changed, and what it costs

12.5 What comes next

That is the whole issuing workflow. Part 4 covers what your recipients and verifiers see, how languages fit together, and what to do when something goes wrong.

→ Chapter 13 · What recipients and verifiers see

You have been working in the console. Everyone else meets your credentials somewhere else — in an email, on a claim page, in a wallet, or on a public verification page they reached by scanning a QR code on a piece of paper.

This chapter is a tour of those screens from the outside. You cannot configure most of it, but you decide what it says, and you should know what your choices produce.

13.1 The recipient's journey

Notification email  ──►  Claim page  ──►  Badge wallet
                            │
                            └──►  Download PDF / image, share, verify

No account is required for the first two steps: "You can download, share and verify without creating an account." An account is only needed to keep credentials in a wallet.

13.2 The claim page

The link in the notification email opens a page headed Congratulations, with the recipient's name and You have received "{name}", the issue date, the credential number, and the rendered image.

From there:

Expiry is not revocation. An expired credential is an accurate historical record — the person did earn it. The wording above is deliberate, and it is why expiry never blocks a download while revocation always does.

13.3 The public verification page

This is the page behind the QR code and behind /v/… links. No sign-in, ever — a verification that required an account would not be a verification.

The headline is one of:

Under Verification details, four independent checks, each Pass / Fail / Needs checking:

Then the content: Issuer, Issued on, Expires on, Credential number, Learning hours, About this credential, Criteria, Related skills and Framework alignment — all of it coming from the definition you wrote in Chapter 9. This is where a well-written Criteria earns its keep.

Actions available to a visitor: Copy link, Share on LinkedIn, Share on X, Print, and View source (JSON).

The PDF is not public. A visitor sees Only the recipient can download the PDF — "Download it from the link in the notification email, or from your badge wallet." The public page masks the recipient's name, so serving the real-name PDF from the same link would make the masking pointless.

Technical details

A collapsible Technical details · raw data section exposes the standard, the credential ID, the issuer DID, the signature, the status list, the raw VC, and downloads for the JSON and the signed JWT.

"Anyone can verify this credential independently with the public key in the DID Document above. Feeding the JWT to an external verifier gives the same result."

That sentence is the product's central claim. Your credentials do not depend on CertLink being trusted, or even present — they can be checked by anyone, with standard tools.

13.4 What the recipient controls

In their wallet, under Visibility — "You decide how much of your information the verification page shows."

Your definition sets the ceiling, not the recipient's preference:

So §9.6 is not merely a default — it is the boundary of what a recipient is allowed to publish about their own credential. Set it thoughtfully in both directions: too open and you have published people's names by default; too closed and a graduate cannot put their own achievement on a CV.

13.5 The badge wallet

Badge wallet lists everything a recipient holds, with a summary — "{total} total · {valid} valid · {expired} expired · {revoked} revoked" — search, filters, and an Expires within 30 days flag.

Credentials from every issuer sit side by side. Yours is one entry among others, which is worth remembering when you design one: the badge image is what makes it recognisable at a glance.

13.6 Your public issuer page

app.certlink.io/issuer/{slug} is your organisation's public profile, and it is where someone goes to answer "is this issuer real?".

The page carries no advertising and no promotional content — it exists to answer one question neutrally. Keep your contact details current: this is where someone who doubts a credential will try to reach you.

13.7 Looking up a credential by number

app.certlink.io/check — Look up by credential number: "Check a credential by its number — no sign-in needed."

This is the fallback when someone has a paper certificate with a smudged QR code, or a number in a spreadsheet and nothing else. Point people here. It is also a good argument for printing the credential number in readable text alongside the QR.

13.8 What comes next

→ Chapter 14 · Languages

CertLink runs in five languages:

English · Bahasa Melayu · 中文 · 日本語 · 한국어

English is the default. Nobody sees anything else until they choose it.

The confusion in this area is not about which languages exist. It is that four different things have a language, they are set in four different places, and only three of them can ever be changed.

14.1 The four

1 · Your console language

"Used for the console and notification emails. It does not change the language printed on credentials already issued."

Per person. Changing yours does nothing to your colleagues, your organisation, or anything you have issued. Language and time zone are chosen separately — you can read the console in English while seeing times in your own zone.

2 · Your organisation's issuing language

"The default language for issued credentials and notification emails. A recipient's own language setting wins over it. The console language is chosen per person in account settings."

This is the default for what goes out. Change it and the next credential you issue follows the new setting; everything already issued is untouched.

3 · The recipient's language

If a recipient has chosen a language on their own account, their notification email arrives in it — their preference beats your default. There is nothing to configure and nothing you can override.

4 · The language printed on the credential

This is the one that catches people.

Each credential records the language it was issued in, alongside the design revision and the signing key. It is what makes a credential reproducible years later — but it also means the language etched into a certificate cannot be corrected. The PNG has been printed and framed; the signed credential is in a wallet.

If a cohort went out in the wrong language, the only remedy is the one from §11.5: revoke and re-issue.

Check the language before a large batch, not after. It is on the same list as checking the recipient count (§10.6) — cheap before, impossible after.

14.2 What the public verification page does

The verification page follows the visitor's language, because a verifier could be anyone, anywhere. But the credential's own content does not move:

"This credential was issued in {language}. The interface follows your language, while the credential content and attachments stay in the language it was issued in."

So an employer in Kuala Lumpur reading a credential issued in Korean gets the page furniture — the headings, the check results, the buttons — in their own language, and the credential's title, criteria and certificate image exactly as they were issued. Which is correct: translating the content would mean showing something other than what was signed.

14.3 Practical guidance

A design is not translated. The words you type into a design — headings, body text, the phrase around [recipient.name] — are part of the layout. They render exactly as typed, in every language. If you need a Malay certificate and an English certificate, that is two designs.

14.4 What comes next

→ Chapter 15 · Announcements, FAQ and support

15.1 Announcements

Announcements in the sidebar lists notices from CertLink — maintenance windows, changes that affect issuing, new capabilities.

Important ones are marked Important and also appear at the top of your dashboard: "New announcements also appear at the top of the dashboard." A newly published notice can pop up once when you open the console; Close dismisses it and it stays in the list.

Check announcements before a large batch. A scheduled maintenance window is exactly the kind of thing you want to know about before, not during, a graduation run.

15.2 Frequently asked questions

Frequently asked questions is CertLink's own FAQ, inside the console, organised by category:

Where an entry exists in more than one language you can switch between View in Korean and View in English.

The FAQ is maintained centrally, so it reflects the current behaviour of the product — worth checking before raising a question, and worth checking after an announcement about a change.

15.3 Getting help

"Please reach out to support with any questions."

Use the contact form at https://certlink.io/contact.

What to include

Support can answer far faster with a few specifics. From Chapter 16's table, the useful ones are:

Do not send recipient personal data in a support request unless you are asked for it. Credential numbers identify the record without identifying the person.

15.4 What comes next

→ Chapter 16 · When something goes wrong

Most problems in CertLink are a rule working as designed rather than a fault. This chapter lists the ones people actually hit, what causes them, and what to do.

16.1 "I cannot issue"

Work down this list. It is ordered by how often each one is the answer.

16.2 "A menu is missing"

Menus you do not have permission for are hidden, not disabled. A missing menu is a role question, not a bug — check Settings → Team (§4.1).

The common surprises:

16.3 "I cannot give a colleague issuing rights"

Their account has not enrolled in two-step verification. The order has to be: invite → they enrol → you raise the role (§4.4).

16.4 "The spreadsheet will not go through"

16.5 "No image or PDF was produced"

The definition has no design connected. The issue screen said No design — no image or PDF will be produced before you ran it. The credential itself is valid and verifiable; it just has no picture.

Connect a design (§9.7) and issue again for future recipients. Existing ones need a revoke and re-issue (§11.5).

16.6 "A row failed with E-CRD-004"

"Some attributes placed on the design have no value." — the design places an attribute that this row has no value for.

This one is a feature. The alternative is a certificate with a blank where a name should be.

16.7 "The certificate does not look like the editor"

Check the Preview (§8.6) — "The editing canvas is an approximation; this image is what actually gets issued."

16.8 "The notification email did not arrive"

If it shows Sent and the recipient still has nothing, Resend (§11.3), then check the address character by character.

16.9 "A recipient says their claim link does not work"

16.10 "I revoked the wrong credential"

It cannot be undone. Issue a replacement (§11.5); the new one has a new identifier and the revoked one stays in the history as a record of what happened.

If you had chosen Suspension instead, Unsuspend would have reversed it — which is the reason for §11.4's advice to suspend when in doubt.

16.11 Error codes

Quote the code when you contact support (§15.3).

Sign-in and accounts

Organisation

Credentials and issuing

Verification

General

16.12 Anything else

If a screen shows a message that is not in this chapter, or something behaves in a way this manual does not describe, contact support (§15.3) with the code, the time and your workspace address.

Appendix A · Glossary

Appendix B · Roles and permissions

Six roles, fourteen permissions.

Two-step verification is mandatory for the Owner and for any role that can issue credentials — Owner, Administrator and Issuer (§3.1, §4.4).

These actions require a recent re-verification even inside an active session — 15 minutes on an ordinary browser, 12 hours on a remembered one (§3.4):

• Issue credentials
• Revoke credentials
• Export recipient data
• Manage signing keys

At least one Owner must always remain (E-ORG-005).

Appendix C · Spreadsheet upload columns

For bulk issuing (§10.4).

The safe way

Download the template from the definition you are about to issue, and do not rename its column headers. The template is generated for that definition — its custom-attribute columns match the attributes that definition needs. A template saved from a different definition, or from before an attribute was added, will not line up.

The template contains two sheets: the data sheet, and a guidance sheet naming the credential and listing the required columns.

File limits

Columns

Column order does not matter — headers are matched by name.

Custom-attribute columns are matched by the attribute's label, or by its full key (custom.something).

Header names the upload recognises

Matching is case-insensitive, and the column heading in every language CertLink supports is accepted — so a template downloaded in one language still uploads correctly if a colleague opens it in another.

⚠️ Anything not on this list is dropped, and the drop is quiet. An unrecognised heading is reported once on the validation screen — "Some columns are not defined … these columns are ignored" — and then the batch proceeds without it. Nothing fails: the credential is issued, the organisation is simply missing, the award date falls back to the issue date, and the number is generated instead of taken from your file. Read that notice when it appears, and prefer the downloaded template over a spreadsheet of your own.

Validation

Every row is classified before anything is issued (§10.5):

Appendix D · Credential number rules

Set on the definition (§9.5). The preview on that screen resolves in your organisation's time zone.

Examples

Reset cycle

Match the reset cycle to the tokens in your rule. {YYMMDD} with Never produces numbers that never repeat but climb indefinitely; {YYMMDD} with Daily gives a clean -0001 each morning. A rule with no date token and a Daily reset produces duplicates.

Starting number sets where the sequence begins — useful when migrating from an existing register.

Appendix E · Public addresses

These are reachable without signing in. They are what you give to recipients, verifiers and partners.

The verification address is permanent. It is printed into QR codes on paper certificates that have already been framed and hung on walls. It will keep answering.

Console addresses (sign-in required)