Bulk issuing
A bulk certificate generator that treats the batch as the unit
Issuing five hundred certificates costs about what issuing five costs. That is the easy half, and most tools solve it. The half that decides whether bulk issuing is safe is what stands between a pasted list and five hundred permanent, signed, publicly verifiable URLs.
At volume, the expensive failure is a successful run
A batch that fails is cheap. You notice, you fix the list, you run it again. The costly outcome is a batch that succeeds with something wrong in it, because success is what makes it permanent: every credential now has its own public page, the recipient's name has been signed with your organisation's key, and a few hundred people have the link in their inbox. Each one is a verifiable credential, which is exactly what makes an error in it durable.
This is the specific reason bulk issuing is not just single issuing in a loop. A misspelling on one certificate is an apology. The same misspelling pattern across a cohort is your organisation's name on four hundred documents that are subtly wrong, and every one of them is the artefact an employer will later be asked to trust. Creating certificates in bulk covers how to get a list into that condition; this page is about what the platform does with it once it arrives.
How a batch runs
There are two ways to get a cohort out, and they differ only in who does the typing. You can send us the list and we run it, which is how most first batches happen. Or, once an award has been set up, you can issue under it yourself whenever you like.
1. The award is set up once
Criteria, artwork, layout and your signing key are agreed with us before anything is issued. This is the part that takes judgement, and it is the part we keep.
2. The list goes in
One recipient per line, pasted straight from a spreadsheet or an email. Up to 500 in a single batch. No file to export, no column order to get wrong.
3. You read what will be signed
Every name and address is shown back to you, parsed, before anything is written. Nothing exists in the database until you confirm this screen.
4. The batch is signed and rendered
Each credential is signed with your organisation's private key, rendered to PDF and PNG, and given a permanent verification page. Then we send the recipient mailing.
Two things in that sequence are deliberately not yours. You cannot create or alter an award, because criteria, artwork and key material are where a credential's meaning is decided and we would rather have that conversation than validate a form. And the recipient mailing is sent by us rather than fired automatically when a batch finishes rendering, so tell us when a batch is going out if it needs to reach people at a particular time.
What the list reader actually handles
Recipient lists do not arrive clean, and they do not arrive in one shape. A comma, a tab, angle brackets, or a single space between the name and the address are all read correctly, because these are the shapes a list is genuinely in when someone copies it out of a spreadsheet, an email client, or their own head:
Ada Okonkwo, ada@example.com
Ada Okonkwo <ada@example.com>
Ada Okonkwo ada@example.com
Ada Okonkwo ada@example.com
"Okonkwo, Ada",ada@example.comThe last line is the one worth dwelling on. A spreadsheet writes a name containing a comma as a quoted field, so a reader that splits on commas turns Ada Okonkwo into a person called "Okonkwo with a surname of Ada". That is the dangerous class of error, because unlike every other malformed line it does not fail. It produces something plausible, and plausible is what gets signed.
Where a line genuinely cannot be read, the error names the line number rather than the file. "Line 14 needs a name and an email address" can be acted on against a block of pasted text; "invalid input" cannot. And where the same address appears twice in one paste, the repeat is dropped rather than the batch rejected, because issuing to someone twice is worse than quietly not issuing to them a second time.
What none of that catches
A parser can only reject lines that are malformed. It has nothing to say about a line that is perfectly well formed and wrong: a name spelled correctly for a different person, an address belonging to a colleague, a cohort list that quietly includes three people who withdrew. No amount of validation reaches that, and any platform claiming otherwise is describing a check it does not have.
Which is why the review screen is a separate step that writes nothing. Every parsed name and address is shown back before the batch exists, and confirming is a second, deliberate action. It is not a confirmation dialog. It is the last moment at which a mistake is still free, and it is positioned there because it is the only control that catches the errors the machinery cannot.
- A ceiling of 500
- One batch carries up to 500 recipients. The list is checked against that ceiling at the review step, before anything is written, and the database enforces the same limit independently. Larger cohorts are split, or we run them.
- People, not rows
- Recipients are matched on email address, so someone earning their third credential from you is one person with three, not three records. An earlier spelling of their name is never overwritten by a later batch.
- Unsigned means unpublished
- A credential that cannot be given its digital signature is not published. It waits. An unsigned certificate renders perfectly and then verifies as "not signed", which is the worst of both outcomes.
Signing happens after the batch is accepted rather than during it, so a large cohort appears as credentials being prepared and then fills in progressively rather than all at once. Recipients are mailed once their own credential is ready, never before. How the signing itself works, and what it does and does not prove, is on the security page.
After the batch
A cohort is not finished when it goes out. Names come back wrong, people change their address, and someone always asks in March for a link they were sent in October. Correcting a name after issuance does not break the verification URL, because that URL is derived from the credential's own credential ID rather than from anything printed on it.
What happened to a batch afterwards is worth knowing too, and it is rarely what people expect. One issuer's 48 credentials, ten months on reports the full set of numbers from a real cohort, including the ones that were less flattering than we expected. If you issue cohort after cohort on a schedule, how this works for training providers is the closer fit.
Frequently asked questions
- Is there a limit on how many recipients I can issue to at once?
- When you issue a batch yourself, 500 recipients is the ceiling for one batch. The list is checked against it at the review step, before anything is written, and the database enforces the same limit independently. It bounds how far a single mistake can travel. Larger cohorts are either split into several batches or sent to us to run, and when we run them there is no practical ceiling.
- What format does the recipient list need to be in?
- One recipient per line, with a name and an email address. Commas, tabs, angle brackets and a plain space between the two all work, so a block copied straight out of a spreadsheet or an email client is usually accepted as-is. There is no file to export and no column order to get wrong. Where a line cannot be read, the error names the line number.
- Do we run the batch, or do you?
- Either. Awards are set up by us, because criteria, artwork and signing keys are decisions rather than form fields. Once an award exists you can issue under it yourself whenever you like, or send us the list and we will run it. Most first batches happen the second way and later ones happen the first. We send the recipient mailing in both cases.
- What happens between confirming a batch and recipients receiving it?
- Each credential is signed with your organisation's private key, rendered to PDF and PNG, and given its own verification page. A large cohort fills in progressively rather than all at once, and recipients are only mailed once their own credential is ready. A credential that cannot be signed is held back rather than published unsigned.
- What if a name is spelled wrong in a batch we already issued?
- Send us the correction. We regenerate that credential and its verification URL does not change, so any link already shared keeps working, including one already added to a LinkedIn profile. Recipients are matched on email address, so a corrected spelling applies to every credential that person holds from you.
Bring us a real cohort
Send us a list you actually need to issue. We will set up the award, run the batch, and show you what every recipient and every employer checking them will see.