Platform Documentation

In a rush? Here is how to send your first batch in under 2 minutes:

1. 1Create a Template: Go to the Dashboard and click "Create New Template". Choose a preset or start blank.
2. 2Add Dynamic Fields: Use the {{Field}} button to place placeholders like {{Name}} and {{Date}} on your design.
3. 3Prepare Data: Create an Excel file with columns matching your placeholders (e.g. a column named "Name" and a column named "Date").
4. 4Run Batch: Click "Run Job" on the template card — a three-step wizard opens: recipients, delivery, review.
5. 5Launch: Pick your Excel file or a recipient list, set the email subject/body (or load a saved template), review and press Launch.

The pieces you reuse across certificates live outside any single template, so a change reaches everything you issue next.

• Attributes. The named fields your certificates can carry — Recipient Name, Course, or one you define yourself like Employee ID. Each becomes a placeholder the builder can place, and a custom one works the moment you create it: no template, gallery design or issued certificate changes.
• Assets. Upload the logos, signatures and seals you place on certificates. They are stored once and available in the builder for every template.
• Phrases. Save the wording you reuse — an opening line, a closing line, a compliance sentence — under a short label, and drop it into any design instead of retyping it.
• Email templates. The covering email that carries a certificate. Write your own or have the AI assistant draft one; drafting spends AI credits from your plan, saving does not.

One month view of everything with a date attached, so a renewal or a scheduled send does not arrive as a surprise.

• What appears. Scheduled sends, certificates that expire that day, and live event days.
• Expiry. A certificate given an expiry date reports itself as expired on its verification page once the date passes — you do not have to do anything for that to happen.
• Renewal reminders. Where a certificate has an expiry, a reminder email can go to the holder before it lapses.

Put a QR code on the screen and let people claim their own certificate. Nobody uploads a spreadsheet, and nobody types attendee names.

• Two modes. Instant issues and emails the certificate the moment someone claims. Collect captures their details without issuing, so you can review and send as a batch later.
• The claim page. Each form has an unguessable public URL at /f/{slug}. Show it as a QR at the venue, or send the link to remote attendees.
• You open and close it. A form only accepts claims while it is active, and you can toggle that live. It also stops on its own at an expiry date or a submission cap, which defaults to 500.
• What you ask for. Email is always collected; add any other fields you need, marking each required or optional. Whatever the attendee submits can be placed on the certificate.
• Everyone lands in a recipient list. Each claim writes the attendee into the list linked to the form, in both modes — so the event leaves you with a reusable audience, not just a pile of certificates.
• One event, one batch. The whole event appears in your history as a single batch, with per-attendee resend if somebody mistypes their address.
• Scanning at the door. A door link opens a scanner for staff to check people in. If the camera is unavailable, the code on the ticket can be typed instead.

Every certificate you issue is a signed credential, not just a page on our site. Anyone can check it against your organisation’s published key — including with CertTrigger switched off.

• Signed on issue. Each certificate is a W3C Verifiable Credential 2.0 / Open Badges 3.0 document, signed with your organisation’s own Ed25519 key. Alter any field and the signature stops matching.
• You are the issuer, not us. Set your organisation’s name and website in Profile → Organization branding. They appear on the credential; CertTrigger never does.
• Public documents. /credentials/{id}.json is the signed credential, /credentials/{id}.jwt the bare token, /orgs/{orgSlug}/did.json your public keys, and /status/{listId} the revocation list. No API key needed.
• Revocation is published. Revoking flips one bit in a signed W3C status list, so even someone holding the file offline can discover it was withdrawn. The credential itself stays valid and keeps being served — that is the point.
• Open Badges 2.0 still works. The old assertion URL is unchanged and supported indefinitely, so anything built against it keeps working.
• Check it yourself. Our single-file verifier at /verify/offline resolves your key, verifies the signature and checks revocation — without calling any CertTrigger API.

For deep integration, use the REST API — issue one certificate or six hundred, each a signed, verifiable credential.

• GETAuthentication: Bearer key from Profile → API keys (Pro and Enterprise plans). Send Authorization: Bearer ct_... on every request.
• POSTPOST /api/v1/certificates: issue one certificate; returns verifyUrl, pdfUrl, credentialUrl (the signed credential) and badgeUrl. It does not email anyone unless you set sendEmail.
• POSTPOST /api/v1/batches: issue to many in one call, from a recipient list or an array of recipients, delivered by email by default. Returns a batchId to poll with GET /api/v1/batches/{id}. Use this rather than looping the single endpoint.
• GETGET /api/v1/templates/{id}/fields: what a design asks for, and which of those you must supply. An unmatched placeholder prints its own label onto the certificate, so it is worth asking first.
• GETGET /api/v1/templates: list your template IDs for integration pickers.
• GETGET /api/v1/certificates and /certificates/{id}: list or inspect what you have issued, including live status and the same links.
• GETGET /api/v1/lists and POST /api/v1/lists/{id}/contacts: read your recipient lists, with the values each one shares across its recipients, and append to them.
• POSTPOST /api/v1/hooks: subscribe a URL to platform events (Zapier, Make, n8n). Every delivery is signed.

Let colleagues issue under your plan without sharing a login.

• Invitations. The plan owner invites members by email. An invitation is single-use and expires, so a forwarded link does not become a standing door.
• Members work on your plan. A member inherits the owner's entitlements — templates, AI, branding, sending — rather than needing a paid plan of their own.
• Usage stays per person. Members keep their own usage counters, so you can see what each of them issued rather than one merged total.
• One bill. Sends made by a member are charged to the owner's allowance, which is what makes a shared mailbox and a shared quota work.
• Seats. A team has a member cap that counts pending invitations as well as accepted ones.

Where sending, access and your issuer identity are configured.

• Sending channel. Send through CertTrigger, or connect your own Gmail, Outlook or SMTP server so certificates arrive from your address. Connected mailbox tokens are encrypted at rest and used only to send.
• Two-factor authentication. Turn on app-based 2FA (TOTP) from Account. You are given single-use recovery codes at setup — store them somewhere other than the phone running the authenticator.
• Devices. Signed-in devices are listed and can be signed out. Changing your password invalidates every existing session, which is the fastest way to remove someone who should not be there.
• API keys. Create scoped Bearer keys in Account. The full key is shown once at creation and only its hash is stored, so a lost key is replaced rather than recovered.
• Issuer identity. Under Profile → Organization branding, set the organisation name and website that appear on every credential you issue, and upload the logo shown on claim and verification pages.