{"id":19755,"date":"2026-08-14T10:34:01","date_gmt":"2026-08-14T10:34:01","guid":{"rendered":"https:\/\/sertifier.com\/blog\/?p=19755"},"modified":"2026-08-14T10:34:01","modified_gmt":"2026-08-14T10:34:01","slug":"credentialing-automation-workflow","status":"publish","type":"post","link":"https:\/\/sertifier.com\/blog\/credentialing-automation-workflow\/","title":{"rendered":"Credentialing automation: workflow design, controls and failure handling"},"content":{"rendered":"<p>Credentialing automation connects an approved event or schedule to the creation, issuance and delivery of a digital certificate or badge. A useful workflow does more than remove manual clicks. It defines when a credential is earned, validates the recipient and achievement data, prevents duplicate issuance, handles failures and leaves evidence that operations teams can reconcile.<\/p>\n<p>The safest starting point is not an API call. It is a written contract between the learning or business process that decides eligibility and the credential system that represents that approved decision.<\/p>\n<div class=\"sertifier-summary-box\">\n<p><strong>Short answer:<\/strong> Automate a governed decision, not an unexplained send action. Define the source event, field contract, approval rule, duplicate control, result evidence and recovery path before launch.<\/p>\n<\/div>\n<h2>Short answer<\/h2>\n<p>A production credentialing automation needs seven connected controls:<\/p>\n<ol>\n<li>A precise trigger that represents an approved business event.<\/li>\n<li>A data contract for recipient, credential and achievement fields.<\/li>\n<li>A stable key that prevents accidental duplicate issuance.<\/li>\n<li>Validation and approval rules before the send step.<\/li>\n<li>Bounded error handling with an accountable work queue.<\/li>\n<li>Delivery and credential-state reconciliation after issuance.<\/li>\n<li>Logs and metrics that distinguish success, rejection, retry and manual<\/li>\n<p>intervention.<\/p>\n<\/ol>\n<p>Choose scheduled, bulk, integration, API or pathway automation only after these rules are clear.<\/p>\n<h2>Choose the automation mode by the source event<\/h2>\n<p>Different programs need different delivery patterns. Use the smallest method that can represent the real eligibility decision reliably.<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Automation mode<\/th>\n<th>Best fit<\/th>\n<th>Primary control question<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Scheduled campaign<\/td>\n<td>A known cohort should receive credentials at a future time<\/td>\n<td>Is the recipient list final and approved before the schedule runs?<\/td>\n<\/tr>\n<tr>\n<td>Bulk upload<\/td>\n<td>A governed file contains an approved cohort<\/td>\n<td>How are file version, required fields and duplicates checked?<\/td>\n<\/tr>\n<tr>\n<td>Native integration<\/td>\n<td>A supported application emits a known completion or business event<\/td>\n<td>Which exact event and status authorize issuance?<\/td>\n<\/tr>\n<tr>\n<td>Workflow tool<\/td>\n<td>Several systems or approval steps must be connected<\/td>\n<td>Where are transformations, secrets and failures governed?<\/td>\n<\/tr>\n<tr>\n<td>Direct API<\/td>\n<td>A custom system needs programmatic issuance and status handling<\/td>\n<td>Who owns authentication, versioning, retries and reconciliation?<\/td>\n<\/tr>\n<tr>\n<td>Credential pathway<\/td>\n<td>A later credential depends on earlier credentials or prerequisites<\/td>\n<td>Which prerequisite states count as complete?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>Sertifier&#8217;s current automation help describes scheduled campaigns, external application triggers and Pathways that can issue a later credential after defined prerequisites are met. Review the current <a href=\"https:\/\/help.sertifier.com\/how-can-i-automate-my-credentials\">automation overview<\/a> before selecting a delivery pattern.<\/p>\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-workflow-v1.webp\"><img loading=\"lazy\" decoding=\"async\" width=\"2400\" height=\"1500\" src=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-workflow-v1.webp\" alt=\"Six credentialing automation stages: trigger, validate, deduplicate, approve, issue and reconcile.\" class=\"wp-image-19753\" title=\"\" srcset=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-workflow-v1.webp 2400w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-workflow-v1-765x478.webp 765w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-workflow-v1-1080x675.webp 1080w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-workflow-v1-768x480.webp 768w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-workflow-v1-1536x960.webp 1536w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-workflow-v1-2048x1280.webp 2048w\" sizes=\"auto, (max-width: 2400px) 100vw, 2400px\" \/><\/a><figcaption class=\"wp-element-caption\">Each stage needs a contract, an owner and a defined failure state.<\/figcaption><\/figure>\n<h2>Define the trigger as an eligibility contract<\/h2>\n<p><code>Course completed<\/code> can hide several different states. A learner may have watched every lesson, passed an assessment, paid a fee, satisfied an attendance rule or received a manual exception. Decide which state actually authorizes the credential.<\/p>\n<p>For each trigger, record:<\/p>\n<ul>\n<li>Source system and event name.<\/li>\n<li>Program and credential version.<\/li>\n<li>Recipient identifier.<\/li>\n<li>Completion, assessment or approval state.<\/li>\n<li>Event time and source record identifier.<\/li>\n<li>Owner allowed to override or replay the event.<\/li>\n<li>Conditions that make the event invalid or too late.<\/li>\n<\/ul>\n<p>Avoid triggering from a screen view, email open or another activity that does not prove eligibility. If a human approval is required, model that approval as a distinct state instead of assuming that the integration replaced it.<\/p>\n<h2>Build a field contract before mapping data<\/h2>\n<p>Write down every required field, its source, allowed format and failure behavior. Do not discover missing data after credentials have been sent.<\/p>\n<h3>Recipient fields<\/h3>\n<ul>\n<li>Stable internal learner or member identifier.<\/li>\n<li>Delivery address when email is used.<\/li>\n<li>Display name and any approved name-format rule.<\/li>\n<li>Locale or language when the credential experience varies.<\/li>\n<li>Privacy or delivery restrictions required by the program.<\/li>\n<\/ul>\n<h3>Credential fields<\/h3>\n<ul>\n<li>Credential program and version.<\/li>\n<li>Title, criteria and evidence reference.<\/li>\n<li>Issue date and expiry date when applicable.<\/li>\n<li>Issuer and responsible program.<\/li>\n<li>Custom attributes required by the design or verification page.<\/li>\n<\/ul>\n<h3>Event fields<\/h3>\n<ul>\n<li>Source event identifier.<\/li>\n<li>Completion or decision timestamp.<\/li>\n<li>Result and approval status.<\/li>\n<li>Course, cohort, campaign or program identifier.<\/li>\n<li>Source-system link or reconciliation reference.<\/li>\n<\/ul>\n<p>Sertifier&#8217;s current API documentation describes Design, Detail, EmailTemplate and Campaign as core components and documents authentication through an organization&#8217;s private API key. It also documents adding credentials through a campaign and publishing credential records. Use the current <a href=\"https:\/\/docs.sertifier.com\/\">Sertifier API documentation<\/a> for exact request, version and authentication requirements. Never place a private key in content, logs or a client-side script.<\/p>\n<h2>Prevent duplicate issuance deliberately<\/h2>\n<p>Automated events can be delivered more than once. A user may retry an action, a workflow may replay after a timeout or an operator may run the same file twice. Treat duplicate prevention as an implementation requirement even when the selected product or integration documentation does not promise idempotency.<\/p>\n<p>Define a business key such as:<\/p>\n<p><code>recipient + credential program version + approved achievement instance<\/code><\/p>\n<p>Before issuance, decide whether the matching record should be rejected, returned as already complete, updated or sent through a controlled reissue process. Do not silently create another credential merely because a second event arrived.<\/p>\n<p>Store enough context to explain the decision:<\/p>\n<ul>\n<li>Source event ID.<\/li>\n<li>Business key.<\/li>\n<li>First-seen and last-seen time.<\/li>\n<li>Credential ID when issued.<\/li>\n<li>Duplicate or replay outcome.<\/li>\n<li>Operator action when manually resolved.<\/li>\n<\/ul>\n<h2>Validate before calling the issue step<\/h2>\n<p>Validation should fail safely and create a work item that explains what needs attention.<\/p>\n<p>Check:<\/p>\n<ol>\n<li>The credential program and version are active.<\/li>\n<li>The source event is an approved eligibility state.<\/li>\n<li>Required recipient and credential fields exist.<\/li>\n<li>Dates and identifiers use accepted formats.<\/li>\n<li>The recipient is not blocked by a privacy or program rule.<\/li>\n<li>The business key has not already produced an active record.<\/li>\n<li>A required human approval is present.<\/li>\n<\/ol>\n<p>Separate invalid data from unavailable infrastructure. Invalid data should not be retried without a change. A temporary connection or service failure may be eligible for a bounded retry under the organization&#8217;s operations policy.<\/p>\n<h2>Put approvals and access around automation<\/h2>\n<p>Automation expands the impact of a configuration error. Limit who can create, activate and change integrations, API keys, credential programs and templates.<\/p>\n<p>Use separate responsibilities where practical:<\/p>\n<ul>\n<li>Program owner approves the claim and eligibility rule.<\/li>\n<li>Credential operations owns the template, campaign and support process.<\/li>\n<li>Technical owner manages connection, secrets and monitoring.<\/li>\n<li>Privacy or security owner reviews data movement and retention.<\/li>\n<li>An authorized approver accepts production changes.<\/li>\n<\/ul>\n<p>Sertifier&#8217;s current <a href=\"https:\/\/help.sertifier.com\/users-permissions\">permissions documentation<\/a> describes separate access for credential operations and integrations. Map those controls to your own change-management and least-access rules rather than granting every operator the same administrative access.<\/p>\n<figure class=\"wp-block-image aligncenter size-large\"><a href=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-outcome-matrix-v1.webp\"><img loading=\"lazy\" decoding=\"async\" width=\"2400\" height=\"1500\" src=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-outcome-matrix-v1.webp\" alt=\"Credential automation outcome matrix for issued, duplicate, invalid data, approval hold, temporary failure, partial delivery and unknown result states.\" class=\"wp-image-19754\" title=\"\" srcset=\"https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-outcome-matrix-v1.webp 2400w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-outcome-matrix-v1-765x478.webp 765w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-outcome-matrix-v1-1080x675.webp 1080w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-outcome-matrix-v1-768x480.webp 768w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-outcome-matrix-v1-1536x960.webp 1536w, https:\/\/sertifier.com\/blog\/wp-content\/uploads\/2026\/08\/credentialing-automation-outcome-matrix-v1-2048x1280.webp 2048w\" sizes=\"auto, (max-width: 2400px) 100vw, 2400px\" \/><\/a><figcaption class=\"wp-element-caption\">Separate business rejection, temporary failure and unknown state so each outcome produces a controlled next action.<\/figcaption><\/figure>\n<h2>Design failure handling before launch<\/h2>\n<p>Every failure should have a known state, owner and next action.<\/p>\n<figure class=\"wp-block-table\">\n<table>\n<thead>\n<tr>\n<th>Outcome<\/th>\n<th>Meaning<\/th>\n<th>Required action<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Issued<\/td>\n<td>Source event and credential result are linked<\/td>\n<td>Confirm delivery and reconciliation evidence<\/td>\n<\/tr>\n<tr>\n<td>Duplicate<\/td>\n<td>The business key already has a governed result<\/td>\n<td>Return the existing state or enter approved reissue flow<\/td>\n<\/tr>\n<tr>\n<td>Invalid data<\/td>\n<td>Required field or rule failed<\/td>\n<td>Route to data owner; do not retry unchanged input<\/td>\n<\/tr>\n<tr>\n<td>Approval missing<\/td>\n<td>Eligibility is incomplete<\/td>\n<td>Hold until the authorized decision exists<\/td>\n<\/tr>\n<tr>\n<td>Dependency unavailable<\/td>\n<td>A required service or connection failed temporarily<\/td>\n<td>Apply bounded retry and alert thresholds<\/td>\n<\/tr>\n<tr>\n<td>Partial delivery<\/td>\n<td>Credential exists but notification or downstream action failed<\/td>\n<td>Preserve the credential state and repair only the failed step<\/td>\n<\/tr>\n<tr>\n<td>Unknown result<\/td>\n<td>The request outcome cannot be confirmed<\/td>\n<td>Reconcile before attempting another issuance<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p>The final state matters more than the HTTP response seen by one component. A timeout can occur after the credential was created. Reconcile against the credential record or another authoritative result before replaying the event.<\/p>\n<h2>Separate issuance from notification<\/h2>\n<p>Credential creation and recipient notification are related but different outcomes. If a credential was issued successfully and an email failed, creating another credential is usually the wrong recovery action.<\/p>\n<p>Track:<\/p>\n<ul>\n<li>Credential created or rejected.<\/li>\n<li>Credential published or held.<\/li>\n<li>Notification requested.<\/li>\n<li>Notification delivered, bounced or unresolved when that evidence exists.<\/li>\n<li>Recipient accessed the credential.<\/li>\n<li>Follow-up or support action.<\/li>\n<\/ul>\n<p>Sertifier&#8217;s scheduled-credentials documentation describes creating, editing and cancelling a scheduled send before its delivery time. Review the current <a href=\"https:\/\/help.sertifier.com\/scheduled-credentials-guide\">scheduled credentials guide<\/a> when the cohort and send time are known in advance.<\/p>\n<h2>Use a reconciliation view<\/h2>\n<p>An operations team needs a daily answer to four questions:<\/p>\n<ol>\n<li>Which source events were eligible?<\/li>\n<li>Which produced a credential?<\/li>\n<li>Which failed, duplicated or remain unresolved?<\/li>\n<li>Which credential results are missing from the source workflow&#8217;s expected<\/li>\n<p>state?<\/p>\n<\/ol>\n<p>Build a reconciliation record with the source event, recipient, program, business key, credential ID, timestamps, current outcome and responsible owner. The view should support replay only after the operator understands whether the original operation completed.<\/p>\n<p>Sertifier&#8217;s API documentation states that webhooks are available for credential events and directs teams to support for setup details. Verify the current event list, payload, authentication and delivery semantics before designing a webhook-dependent reconciliation process. Do not invent fields or delivery guarantees that are not documented.<\/p>\n<h2>Test one happy path and every important failure<\/h2>\n<p>The acceptance plan should include more than one successful learner.<\/p>\n<h3>Happy-path checks<\/h3>\n<ul>\n<li>Correct trigger produces one credential.<\/li>\n<li>Title, recipient, criteria, dates and custom fields are correct.<\/li>\n<li>Verification page represents the approved claim.<\/li>\n<li>Notification and recipient access work as intended.<\/li>\n<li>Source event and credential ID can be reconciled.<\/li>\n<\/ul>\n<h3>Failure-path checks<\/h3>\n<ul>\n<li>Same event is delivered twice.<\/li>\n<li>Required field is missing.<\/li>\n<li>Recipient identifier conflicts with another record.<\/li>\n<li>Approval is absent.<\/li>\n<li>Expiry date is invalid.<\/li>\n<li>Connection fails before a response.<\/li>\n<li>Connection times out after the system may have processed the request.<\/li>\n<li>Notification fails after successful issuance.<\/li>\n<li>Operator replays an event from the work queue.<\/li>\n<\/ul>\n<p>Record expected and observed results for each case. A workflow is not ready because its demo path worked once.<\/p>\n<h2>Use current integrations as bounded examples<\/h2>\n<p>Sertifier&#8217;s public LearnDash guide describes automated issuance after course completion. Its Make guide describes event-triggered workflows and a campaign identifier\/API-key setup. These are current examples of delivery patterns, not proof that every LMS, CRM or workflow tool behaves the same way.<\/p>\n<ul>\n<li>Review the <a href=\"https:\/\/help.sertifier.com\/sertifier-learndash-integration\">LearnDash integration example<\/a><\/li>\n<p>for a course-completion pattern.<\/p>\n<li>Review the <a href=\"https:\/\/help.sertifier.com\/sertifier-make-integration\">Make integration example<\/a><\/li>\n<p>for a configurable workflow pattern.<\/p>\n<\/ul>\n<p>Verify current availability, authentication and field behavior for the exact system in scope before implementation.<\/p>\n<h2>Add pathways only after individual issuance is reliable<\/h2>\n<p>A multi-step pathway increases the number of states that need reconciliation. First prove that each underlying credential is issued accurately.<\/p>\n<p>Sertifier&#8217;s current Pathways documentation describes prerequisite logic and an automatic-send option after completion conditions are met. Review <a href=\"https:\/\/help.sertifier.com\/what-are-pathways\">Pathways<\/a> for the current product flow. Then define how corrections, removed prerequisites and late-arriving events affect the pathway before enabling automatic progression.<\/p>\n<h2>Measure the workflow without inventing savings<\/h2>\n<p>Track operational results first:<\/p>\n<ul>\n<li>Eligible source events.<\/li>\n<li>Successful unique issuances.<\/li>\n<li>Duplicate events prevented.<\/li>\n<li>Invalid records by field and source.<\/li>\n<li>Approval holds.<\/li>\n<li>Retry attempts and exhausted failures.<\/li>\n<li>Unknown results requiring reconciliation.<\/li>\n<li>Time from approved event to issued credential.<\/li>\n<li>Manual interventions by cause.<\/li>\n<\/ul>\n<p>These measures reveal where automation is moving work rather than removing it. Do not claim time savings, engagement improvement or revenue impact until the organization has a dated baseline and verified post-launch evidence.<\/p>\n<h2>Roll out in a bounded sequence<\/h2>\n<ol>\n<li>Choose one credential and one authoritative trigger.<\/li>\n<li>Approve the field, duplicate, failure and correction contracts.<\/li>\n<li>Test with non-public records.<\/li>\n<li>Run a small monitored cohort.<\/li>\n<li>Reconcile every source event and credential result.<\/li>\n<li>Correct the workflow and repeat the failure tests.<\/li>\n<li>Expand volume only after duplicate and unknown-result controls pass.<\/li>\n<li>Add more programs or pathway dependencies one at a time.<\/li>\n<\/ol>\n<h2>Questions to ask a credential automation platform<\/h2>\n<ul>\n<li>Which scheduling, bulk, integration, API and pathway methods are currently<\/li>\n<p>supported?<\/p>\n<li>How are credentials and campaigns identified?<\/li>\n<li>What authentication and API-version rules apply?<\/li>\n<li>Which operations create, publish, update or remove a credential?<\/li>\n<li>What happens when the same event arrives twice?<\/li>\n<li>Which errors are safe to retry?<\/li>\n<li>Which webhooks exist, and how are they authenticated and redelivered?<\/li>\n<li>How can operators reconcile an unknown result?<\/li>\n<li>Which permissions control integrations and issuance?<\/li>\n<li>What reports connect source events to credential results?<\/li>\n<\/ul>\n<p>The first five questions may be answered by public documentation. Duplicate, retry, webhook and reconciliation details require explicit current evidence.<\/p>\n<h2>Automate the governed decision<\/h2>\n<p>Credentialing automation works when it represents a precise eligibility decision, not when it merely moves recipient rows faster. Define the trigger, data, duplicate, approval, failure and reconciliation contracts first. Then choose the delivery method that can satisfy them.<\/p>\n<p>Explore Sertifier&#8217;s current <a href=\"https:\/\/sertifier.com\/solutions\/automation\">credentialing automation solution<\/a> or <a href=\"https:\/\/sertifier.com\/request-a-demo\">discuss your workflow<\/a> before mapping a production integration.<\/p>\n<div class=\"sertifier-conversion-cta\">\n<p><strong>Explore credentialing automation<\/strong><\/p>\n<p>Review how scheduled, integration-triggered and API-based issuance can fit your governed credential workflow.<\/p>\n<p><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/sertifier.com\/solutions\/automation\">Explore automation<\/a><\/p>\n<\/div>\n<h2>Frequently asked questions<\/h2>\n<h3>What is credentialing automation?<\/h3>\n<p>Credentialing automation is a governed workflow that creates, issues or delivers a digital certificate or badge after a defined schedule, approved event or prerequisite state.<\/p>\n<h3>Should a course completion automatically issue a credential?<\/h3>\n<p>Only when course completion is the approved eligibility decision. If an assessment, attendance rule, payment, review or manual approval is also required, the trigger should wait for that complete state.<\/p>\n<h3>How do you prevent duplicate certificates or badges?<\/h3>\n<p>Define a stable business key using the recipient, credential program version and achievement instance. Check that key before issuance and route repeats to an existing-result or controlled reissue process.<\/p>\n<h3>Is a timeout safe to retry?<\/h3>\n<p>Not automatically. The original request may have completed before the timeout. Reconcile against an authoritative credential result before sending another issuance request.<\/p>\n<h3>What should be tested before launch?<\/h3>\n<p>Test one correct issuance plus duplicate events, missing fields, absent approval, connection failures, unknown results, notification failure and operator replay. Record expected and observed outcomes for each.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Design a governed credentialing automation workflow across triggers, data validation, approvals, duplicate prevention, failure handling and reconciliation.<\/p>\n","protected":false},"author":3,"featured_media":19752,"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-19755","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\/19755","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=19755"}],"version-history":[{"count":1,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts\/19755\/revisions"}],"predecessor-version":[{"id":19760,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/posts\/19755\/revisions\/19760"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/media\/19752"}],"wp:attachment":[{"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/media?parent=19755"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/categories?post=19755"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sertifier.com\/blog\/wp-json\/wp\/v2\/tags?post=19755"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}