{"id":19794,"date":"2026-08-27T09:52:12","date_gmt":"2026-08-27T09:52:12","guid":{"rendered":"https:\/\/sertifier.com\/blog\/?p=19794"},"modified":"2026-08-27T09:52:13","modified_gmt":"2026-08-27T09:52:13","slug":"digital-credential-email-delivery","status":"publish","type":"post","link":"https:\/\/sertifier.com\/blog\/digital-credential-email-delivery\/","title":{"rendered":"Digital credential email delivery: bounce prevention and acceptance checklist"},"content":{"rendered":"<p>Issuing a digital credential and delivering its notification are separate results. A platform can create a valid credential while the recipient address is wrong, the message is rejected, or the recipient cannot find or use the credential link.<\/p>\n<p>Build the delivery workflow around observable states. Validate recipient data, use an authenticated sending identity, classify provider responses, preserve a safe resend path, and confirm that the recipient can open the intended credential. No platform can guarantee inbox placement for every domain.<\/p>\n<div class=\"sertifier-summary-box\">\n<p><strong>Short answer:<\/strong> Treat credential issuance, email notification and recipient access as separate results. Validate the source data, authenticate the sending identity, classify provider responses and preserve one governed resend path without creating a duplicate credential.<\/p>\n<\/div>\n<h2>Short answer<\/h2>\n<p>A reliable credential email delivery workflow needs eight controls:<\/p>\n<ol>\n<li>Keep credential issuance, email notification and recipient access as separate states.<\/li>\n<li>Validate recipient addresses and campaign data before the send.<\/li>\n<li>Use a clear sender identity and follow the receiving provider&#8217;s current authentication rules.<\/li>\n<li>Test one bounded sample across the recipient domains that matter.<\/li>\n<li>Record delivered, deferred, bounced and unknown results without turning them into one generic failure.<\/li>\n<li>Correct the source record before resending to a changed address.<\/li>\n<li>Give recipients a support and recovery route that does not create a second credential accidentally.<\/li>\n<li>Measure delivery, acceptance and credential use separately.<\/li>\n<\/ol>\n<p>The goal is not a claimed \u201czero bounce rate.\u201d The goal is a controlled process that can explain what happened to each notification and what the operator may do next.<\/p>\n<h2>Define delivery acceptance before choosing a platform<\/h2>\n<p>\u201cSent\u201d usually means a system accepted a request to create or queue a message. It does not prove that the receiving server accepted the message, that the message reached the inbox, or that the intended person opened the credential.<\/p>\n<p>Define the minimum acceptable journey before comparing products:<\/p>\n<ul>\n<li>One approved credential is created for the intended recipient.<\/li>\n<li>The notification is sent from the expected identity.<\/li>\n<li>The receiving system returns a classified result.<\/li>\n<li>The recipient can identify the issuer and reason for the message.<\/li>\n<li>The credential link resolves to the intended record.<\/li>\n<li>A failed or missing notification can be investigated without duplicate issuance.<\/li>\n<li>The operator can correct recipient data and resend under a governed rule.<\/li>\n<\/ul>\n<p>This page owns that delivery and recipient-acceptance job. For source-event, approval, duplicate prevention and issuance controls, use the <a href=\"https:\/\/sertifier.com\/blog\/credentialing-automation-workflow\/\">credentialing automation workflow<\/a>.<\/p>\n<h2>Separate issuance, notification and access<\/h2>\n<p>Treat the three layers as related records, not one status label.<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Layer<\/th>\n<th>Success means<\/th>\n<th>Failure example<\/th>\n<th>Authoritative evidence<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Credential issuance<\/td>\n<td>One approved credential record exists with the intended data<\/td>\n<td>Rejected request, invalid campaign or duplicate record<\/td>\n<td>Credential platform response and credential ID<\/td>\n<\/tr>\n<tr>\n<td>Email notification<\/td>\n<td>The provider processed the message and returned a classified delivery result<\/td>\n<td>Hard bounce, temporary deferral or unknown result<\/td>\n<td>Message event, provider response and timestamp<\/td>\n<\/tr>\n<tr>\n<td>Recipient access<\/td>\n<td>The intended recipient can reach and interpret the credential<\/td>\n<td>Wrong person, broken link, filtered message or inaccessible page<\/td>\n<td>Recipient support evidence and credential-page check<\/td>\n<\/tr>\n<tr>\n<td>Credential use<\/td>\n<td>The recipient or verifier performs the intended action<\/td>\n<td>Notification opened but credential never accepted or shared<\/td>\n<td>Credential view, acceptance or verification event<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>A delivered message does not prove recipient acceptance. An open event does not prove the recipient understood the credential. A valid credential remains valid even when its first notification failed, provided the issuance record itself is correct.<\/p>\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-evidence-map-v1.webp\"><img loading=\"lazy\" decoding=\"async\" width=\"2400\" height=\"1800\" src=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-evidence-map-v1.webp\" alt=\"Evidence map connecting source roster, credential record, message events, support corrections and recipient access.\" class=\"wp-image-19792\" title=\"\" srcset=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-evidence-map-v1.webp 2400w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-evidence-map-v1-637x478.webp 637w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-evidence-map-v1-900x675.webp 900w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-evidence-map-v1-768x576.webp 768w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-evidence-map-v1-1536x1152.webp 1536w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-evidence-map-v1-2048x1536.webp 2048w\" sizes=\"auto, (max-width: 2400px) 100vw, 2400px\" \/><\/a><figcaption class=\"wp-element-caption\">Keep each delivery decision in the system that can explain and authorize it.<\/figcaption><\/figure>\n<h2>Map every source of truth<\/h2>\n<p>One delivery incident can touch several systems. Assign each decision to the record allowed to answer it.<\/p>\n<ul>\n<li>The LMS, HRIS, event or registration system owns the submitted recipient data.<\/li>\n<li>The credential program owns eligibility, approval and the intended claim.<\/li>\n<li>The credential platform owns the issued record, campaign and credential URL.<\/li>\n<li>The email provider and receiving server supply message-processing evidence.<\/li>\n<li>The recipient support process owns identity-safe correction and escalation.<\/li>\n<li>The verification page owns the externally visible credential presentation.<\/li>\n<\/ul>\n<p>Do not edit a failed email address only inside a temporary resend screen if the source roster will overwrite it on the next run. Do not issue a second credential merely because the first notification was missed.<\/p>\n<h2>Validate recipient and campaign data before sending<\/h2>\n<p>Most preventable delivery failures begin before the email provider sees the message. Run deterministic checks on the source data:<\/p>\n<ul>\n<li>Trim spaces and reject empty addresses.<\/li>\n<li>Normalize case for comparison while preserving the submitted display value.<\/li>\n<li>Detect obvious syntax errors and duplicated recipient rows.<\/li>\n<li>Keep one stable source identifier beside the email address.<\/li>\n<li>Confirm the intended campaign, credential type and recipient name.<\/li>\n<li>Separate corrected addresses from newly eligible recipients.<\/li>\n<li>Prevent a second issuance when the source event is replayed.<\/li>\n<\/ul>\n<p>Sertifier&#8217;s current <a href=\"https:\/\/help.sertifier.com\/can-i-send-credentials-to-multiple-recipients-at-once\">bulk-sending documentation<\/a> describes adding multiple recipients through a sample spreadsheet. The upload mechanism does not remove the issuer&#8217;s responsibility to validate the source list and the intended campaign before release.<\/p>\n<h2>Use an authenticated and recognizable sender identity<\/h2>\n<p>Inbox placement is controlled by receiving providers and recipient behavior, not by a credential vendor alone. Evaluate the exact sending domain, message type and recipient population.<\/p>\n<p>Google&#8217;s current <a href=\"https:\/\/support.google.com\/mail\/answer\/81126?hl=en\" target=\"_blank\" rel=\"noopener\">email sender guidelines<\/a> require authentication and other controls for mail sent to personal Gmail accounts. The requirements differ by sender volume. The guide also recommends clear sender identity, accurate headers, gradual volume changes and monitoring of provider responses.<\/p>\n<p>For a third-party credential platform, verify:<\/p>\n<ul>\n<li>Which domain appears in the visible From address.<\/li>\n<li>Which domain is authenticated by SPF and DKIM.<\/li>\n<li>Whether DMARC alignment applies to the configured sending identity.<\/li>\n<li>Who owns DNS changes and verifies the records.<\/li>\n<li>Whether credential notification and promotional traffic are separated.<\/li>\n<li>Which provider responses and failure reasons are visible to the issuer.<\/li>\n<\/ul>\n<p>Sertifier&#8217;s current <a href=\"https:\/\/help.sertifier.com\/email-domain\">email-domain documentation<\/a> describes a custom sender address and the DNS records shown during setup. The feature is a sender-identity control. It is not proof that every receiving provider will place every message in the inbox.<\/p>\n<h2>Test a bounded recipient-domain sample<\/h2>\n<p>Before a high-volume campaign, issue test credentials only to controlled accounts that represent the recipient domains and devices that matter. Use non-production names and claims, then remove or clearly mark the test records according to the program policy.<\/p>\n<p>Check the complete journey:<\/p>\n<ol>\n<li>The expected sender, subject and recipient are visible.<\/li>\n<li>The message is accepted or a specific provider response is recorded.<\/li>\n<li>The credential button and plain URL resolve correctly.<\/li>\n<li>The recipient sees the intended issuer, credential and support route.<\/li>\n<li>Mobile and desktop layouts preserve the primary action.<\/li>\n<li>A resend does not create a second credential.<\/li>\n<li>A corrected address remains tied to the approved recipient record.<\/li>\n<\/ol>\n<p>Do not publish a vendor comparison from one test inbox. A test is acceptance evidence for that configuration and moment, not a universal deliverability ranking.<\/p>\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-failure-matrix-v1.webp\"><img loading=\"lazy\" decoding=\"async\" width=\"2400\" height=\"2025\" src=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-failure-matrix-v1.webp\" alt=\"Decision matrix for hard bounce, deferred, missing email, broken credential link and unknown delivery states.\" class=\"wp-image-19793\" title=\"\" srcset=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-failure-matrix-v1.webp 2400w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-failure-matrix-v1-567x478.webp 567w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-failure-matrix-v1-800x675.webp 800w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-failure-matrix-v1-768x648.webp 768w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-failure-matrix-v1-1536x1296.webp 1536w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credential-email-delivery-failure-matrix-v1-2048x1728.webp 2048w\" sizes=\"auto, (max-width: 2400px) 100vw, 2400px\" \/><\/a><figcaption class=\"wp-element-caption\">Choose the next action from the observed state instead of applying the same resend to every failure.<\/figcaption><\/figure>\n<h2>Classify delivery failures before choosing an action<\/h2>\n<p>Use the provider&#8217;s actual response and the credential record together.<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Observed state<\/th>\n<th>Likely interpretation<\/th>\n<th>Safe next action<\/th>\n<th>Action to block<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Address rejected permanently<\/td>\n<td>Invalid address, nonexistent mailbox or permanent policy rejection<\/td>\n<td>Confirm the source address, correct it through the authorized process, then resend the existing credential<\/td>\n<td>Repeated automatic resend to the unchanged address<\/td>\n<\/tr>\n<tr>\n<td>Message deferred<\/td>\n<td>Temporary provider, rate or reputation condition<\/td>\n<td>Preserve the response, wait for the documented retry path and monitor the final state<\/td>\n<td>Treating a temporary result as delivered or issuing again<\/td>\n<\/tr>\n<tr>\n<td>Provider accepted, recipient cannot find it<\/td>\n<td>Filtering, wrong inbox, institutional controls or recipient confusion<\/td>\n<td>Check junk folders, sender identity, link and support guidance<\/td>\n<td>Claiming inbox placement from provider acceptance alone<\/td>\n<\/tr>\n<tr>\n<td>Credential link fails<\/td>\n<td>Notification succeeded but recipient access failed<\/td>\n<td>Repair or escalate the credential-page issue under its own incident path<\/td>\n<td>Resending the same broken link repeatedly<\/td>\n<\/tr>\n<tr>\n<td>Status unknown<\/td>\n<td>Event or integration state cannot establish a final result<\/td>\n<td>Reconcile message and credential identifiers before any retry<\/td>\n<td>Blind retry that may duplicate messages or records<\/td>\n<\/tr>\n<tr>\n<td>Wrong person received the message<\/td>\n<td>Source-data or identity-control failure<\/td>\n<td>Stop, follow the organization&#8217;s privacy and incident process, correct the source and assess exposure<\/td>\n<td>Quietly resending without incident review<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>Sertifier&#8217;s current <a href=\"https:\/\/help.sertifier.com\/what-are-credential-reports\">credential reports documentation<\/a> states that undelivered credentials expose specific failure reasons and that those delivery-failure logs are visible for 30 days from issuance. Build the operating review cadence around the actual retention available in the product, and export only when the organization&#8217;s approved data policy requires it.<\/p>\n<h2>Design correction and resend as one controlled workflow<\/h2>\n<p>A resend should reuse the valid credential when only the notification failed. Before acting, confirm the credential ID, recipient identity, approved email change and the last provider result.<\/p>\n<p>Sertifier&#8217;s current <a href=\"https:\/\/help.sertifier.com\/resend-a-credential-email-to-my-recipient\">resend documentation<\/a> describes the Send Again action in Analytics > Credentials. Its <a href=\"https:\/\/help.sertifier.com\/some-of-my-recipients-havent-received-their-certificates.-what-might-be-wrong\">missing-email guidance<\/a> adds checks for address errors, alternate inboxes, spam folders, institutional filters, custom email domains and support escalation.<\/p>\n<p>Translate those product actions into a local decision rule:<\/p>\n<ul>\n<li>Resend only when the existing credential is correct.<\/li>\n<li>Correct the approved recipient record before sending to a different address.<\/li>\n<li>Keep the old and new address handling within the organization&#8217;s privacy rule.<\/li>\n<li>Record who authorized the correction and why.<\/li>\n<li>Escalate repeated failures with the credential ID, provider response and timestamps.<\/li>\n<li>Avoid deleting a credential merely to clear a delivery problem.<\/li>\n<\/ul>\n<h2>Make the email useful after it arrives<\/h2>\n<p>Deliverability is only the first half of recipient acceptance. The message should help an unexpected recipient decide whether it is legitimate and what to do next.<\/p>\n<p>Include:<\/p>\n<ul>\n<li>A recognizable issuer and sender identity.<\/li>\n<li>The reason the recipient earned the credential.<\/li>\n<li>The credential title without inflated claims.<\/li>\n<li>One clear button and a visible destination.<\/li>\n<li>A support route for name, address or credential errors.<\/li>\n<li>A brief explanation of verification and sharing where relevant.<\/li>\n<\/ul>\n<p>Avoid deceptive urgency, unexplained attachments and vague links. Keep the visible message consistent with the issued credential and verification page.<\/p>\n<h2>Evaluate a platform with evidence, not a bounce-rate promise<\/h2>\n<p>Ask vendors to demonstrate the exact workflow with your controlled data.<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Evaluation question<\/th>\n<th>Evidence to request<\/th>\n<th>Why it matters<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Can issuance and notification states be separated?<\/td>\n<td>One credential with successful, failed and resent notification examples<\/td>\n<td>Prevents duplicate issuance during delivery support<\/td>\n<\/tr>\n<tr>\n<td>Which sender identity is visible and authenticated?<\/td>\n<td>Current domain setup flow and test headers<\/td>\n<td>Connects brand recognition to provider requirements<\/td>\n<\/tr>\n<tr>\n<td>Are failure reasons exposed?<\/td>\n<td>Redacted hard-bounce, deferral and unknown-state examples<\/td>\n<td>Operators need different actions for different failures<\/td>\n<\/tr>\n<tr>\n<td>Can an existing credential be resent?<\/td>\n<td>A controlled resend with an unchanged credential ID<\/td>\n<td>Confirms recovery without a duplicate record<\/td>\n<\/tr>\n<tr>\n<td>How are recipient corrections governed?<\/td>\n<td>Role, audit and source-system handoff<\/td>\n<td>Reduces wrong-person and stale-roster risk<\/td>\n<\/tr>\n<tr>\n<td>What is the evidence-retention window?<\/td>\n<td>Current product documentation or contract<\/td>\n<td>Determines review and export cadence<\/td>\n<\/tr>\n<tr>\n<td>Does the recipient route work without the email?<\/td>\n<td>Direct verification or credential access test<\/td>\n<td>Keeps notification failure from becoming credential loss<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>Do not accept an unlabeled platform-wide bounce percentage as proof for your program. Recipient domains, source-list quality, sender configuration, volume, content and provider policy all affect the observed result.<\/p>\n<h2>Use this pre-release acceptance checklist<\/h2>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Gate<\/th>\n<th>Acceptance evidence<\/th>\n<th>Blocking failure<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Eligibility<\/td>\n<td>Approved recipient and one intended credential<\/td>\n<td>Delivery list becomes the eligibility source<\/td>\n<\/tr>\n<tr>\n<td>Recipient data<\/td>\n<td>Syntax, duplicate and source-ID checks pass<\/td>\n<td>Unknown or conflicting address remains<\/td>\n<\/tr>\n<tr>\n<td>Sender identity<\/td>\n<td>Visible sender and authentication configuration are verified<\/td>\n<td>From identity is unexpected or unverified<\/td>\n<\/tr>\n<tr>\n<td>Message<\/td>\n<td>Clear issuer, claim, destination and support route<\/td>\n<td>Misleading subject, claim or link<\/td>\n<\/tr>\n<tr>\n<td>Test send<\/td>\n<td>Representative controlled domains and devices pass<\/td>\n<td>Critical domain or primary link fails<\/td>\n<\/tr>\n<tr>\n<td>Failure handling<\/td>\n<td>Hard, temporary and unknown states have named actions<\/td>\n<td>Every failure triggers the same blind resend<\/td>\n<\/tr>\n<tr>\n<td>Correction<\/td>\n<td>Authorized source update and audit evidence exist<\/td>\n<td>Address is changed only in an ad hoc screen<\/td>\n<\/tr>\n<tr>\n<td>Recipient access<\/td>\n<td>Credential page opens and matches the issued record<\/td>\n<td>Email succeeds but the credential route fails<\/td>\n<\/tr>\n<tr>\n<td>Measurement<\/td>\n<td>Delivery, acceptance and credential-use events stay separate<\/td>\n<td>\u201cSent\u201d is reported as delivered or accepted<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>Save the release evidence with timestamps, test-recipient purpose, credential ID and provider response. Do not include real customer or employee data in a public checklist or screenshot.<\/p>\n<h2>Measure delivery, acceptance and use separately<\/h2>\n<p>Use metrics only when their definitions and sources are documented.<\/p>\n<ul>\n<li>Issuance: approved requests, credentials created, duplicates prevented and failed issue requests.<\/li>\n<li>Notification: queued, provider accepted, deferred, hard bounced and unresolved messages.<\/li>\n<li>Recipient support: missing-email cases, corrected addresses, resends and escalations.<\/li>\n<li>Acceptance: credential-page visits or explicit claim actions where instrumentation is verified.<\/li>\n<li>Credential use: shares, verifier visits and other documented downstream actions.<\/li>\n<li>Business outcomes: only from the authoritative product and CRM systems with a trustworthy join.<\/li>\n<\/ul>\n<p>A resend can improve recipient access while increasing message count. A low bounce count can hide unobserved filtering. Report the states, denominators, date window and exclusions instead of compressing the workflow into a single \u201cdelivery rate.\u201d<\/p>\n<div class=\"sertifier-conversion-cta\">\n<p><strong>Test your credential delivery workflow<\/strong><\/p>\n<p>Map recipient data, sender identity, provider responses, correction, resend and credential access before a high-volume campaign.<\/p>\n<p><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/sertifier.com\/request-a-demo\">Discuss your credential program<\/a><\/p>\n<\/div>\n<h2>Frequently asked questions<\/h2>\n<h3>Does \u201csent\u201d mean a credential email reached the inbox?<\/h3>\n<p>No. It normally proves only that a system accepted or queued the send request. Receiving-provider acceptance, inbox placement and recipient access are different observations.<\/p>\n<h3>Should a failed email create a new credential?<\/h3>\n<p>Usually no. If the existing credential and recipient identity are correct, repair the notification path and resend the existing credential under the program&#8217;s approved rule.<\/p>\n<h3>Can a platform guarantee the lowest bounce rate?<\/h3>\n<p>Not responsibly for every issuer and recipient population. List quality, sender authentication, domain reputation, sending pattern, message content and receiver policy all affect delivery. Require evidence from your own controlled acceptance test.<\/p>\n<h3>What should an issuer check first when a recipient reports a missing email?<\/h3>\n<p>Confirm the recipient address and credential ID, read the current delivery result, check the sender and credential link, and then follow the documented resend or escalation path.<\/p>\n<h3>Is a custom email domain enough to guarantee delivery?<\/h3>\n<p>No. It can create a recognizable and configurable sender identity, but the sending setup still has to meet applicable provider requirements and the recipient system still controls message acceptance and placement.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Design a credential email delivery workflow across recipient data, sender identity, provider responses, bounce recovery, resend and recipient acceptance.<\/p>\n","protected":false},"author":3,"featured_media":19791,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"","rank_math_focus_keyword":"","rank_math_canonical_url":"","footnotes":""},"categories":[1439],"tags":[],"class_list":["post-19794","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-corporate-training"],"_links":{"self":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts\/19794","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/comments?post=19794"}],"version-history":[{"count":1,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts\/19794\/revisions"}],"predecessor-version":[{"id":19795,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts\/19794\/revisions\/19795"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/media\/19791"}],"wp:attachment":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/media?parent=19794"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/categories?post=19794"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/tags?post=19794"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}