A certificate number helps you find an award record. A verification link helps a reader inspect that record. When a training team also keeps its own reference number, all three values can belong to the same award without being interchangeable.<\/p>\n
Before your next certificate batch, decide which value comes from your internal register, which identifies the issued credential, and which link recipients should share. This guide gives you a practical mapping example and checks for preventing mismatched records.<\/p>\n
These are recommended operating distinctions, not a claim that every platform uses the same field names or supports custom numbering. A printed number alone does not establish who issued the award or whether its details are correct.<\/p>\n
Sertifier’s Typeform integration documentation<\/a> identifies The certificate design guide<\/a> also distinguishes fixed text from attributes: fixed text stays the same on every certificate, while attributes can include the Credential ID. If each recipient needs a different identifier, putting one example number into a fixed text box will not accomplish that.<\/p>\n For issued records, Sertifier documents opening a credential by clicking its ID in the delivered credentials view<\/a>. Recipients can use their credential page’s verification action or search Verified with the Certificate ID they received, as explained in the verification instructions<\/a>.<\/p>\n Imagine a fictional training team whose internal register already uses TRN-042<\/strong>. After issuing the approved award, it records the platform-generated credential ID and the supplied verification link alongside that reference.<\/p>\n Sample A: one award, connected records<\/strong><\/p>\n Internal register<\/strong> Issued credential<\/strong> Reader’s destination<\/strong> This example deliberately does not invent a working credential ID or public URL. In your own register, replace the descriptions with the actual issued values. Keep unnecessary personal information out of shared examples and public-facing references.<\/p>\n Suppose support receives a question about TRN-042. The operator uses the register to find the corresponding credential ID, opens its supplied link, and compares the recipient, issuer and achievement. Searching the public verifier for TRN-042 would only be appropriate if that verifier explicitly supports the issuer’s custom reference. Do not assume it does.<\/p>\n If the certificate also carries a QR code, use the separate QR print proof checklist<\/a> to test scanning and destination accuracy on the finished output.<\/p>\n When an award needs a correction, start with the existing record and your program’s correction policy. Do not issue a duplicate merely because someone supplied the internal reference instead of the platform ID.<\/p>\n After an authorized change, check the current credential and its link again. If the workflow creates a replacement record, retain the old-to-new relationship in your internal register and give the recipient the correct current link. Confirm the platform’s documented behavior before promising that an ID or URL will remain unchanged.<\/p>\n Moving an entire program between platforms needs a broader credential migration plan<\/a>. The simple register here is for day-to-day issuance, not a substitute for a migration audit.<\/p>\n No. An organization may use \u201ccertificate number\u201d for its own reference, while the issuing platform assigns a different ID. Label the values clearly and check which one the verifier accepts.<\/p>\n No. A number is a way to identify a record. The reader still needs to inspect the issuer and credential details. Technical verification requirements are covered in the credential verification workflow guide<\/a>.<\/p>\n The cited integration documentation supports custom attributes and describes a separately generated credential ID. Confirm the supported mapping for your chosen issuance route before promising that your internal number can replace a system ID or work in a public lookup.<\/p>\ncredential.id<\/code> as a value generated uniquely for each issued credential. It separately describes mapping form responses to custom attributes. A custom reference supplied through such a mapping should not be assumed to replace the generated credential ID.<\/p>\nA sample register with two different identifiers<\/h2>\n
Issuer reference: TRN-042<\/p>\n
Credential ID: the actual ID assigned to this award<\/p>\n
Verification link: the supplied address for that same credential<\/p>Check the mapping before sending a batch<\/h2>\n
\n
Handle corrections without losing the connection<\/h2>\n
Frequently asked questions<\/h2>\n
Is a certificate number always the credential ID?<\/h3>\n
Does a unique number make a certificate authentic?<\/h3>\n
Can I use my own numbering format in Sertifier?<\/h3>\n
Plan your certificate workflow<\/h2>\n