Open edX digital badges with Credly and Accredible

The badge flow has four stages, and each one can fail without an obvious error for the learner. A learner meets the completion criteria set on the course, the platform records that completion and raises a badge event, the integration builds a request to the badge provider using the fields that provider requires, and the learner receives a claim link or a record to add to a wallet. Before you configure anything, write this sequence out for your own course with one row per stage and a named owner for each row. A missing badge can start at any of the four stages, so the table is what lets your team trace it.

Confirm ownership of each step before you build. The Open edX documentation for your release should state whether the LMS or Credentials emits the completion event, which service holds the badge configuration, and which service calls the external provider. Do not rely on a diagram from a blog post or an older release, because the split may differ between releases and between deployment methods. Ask your implementation partner or the Open edX community for the current pages covering each step, then record the answer in your runbook together with the release and deployment method you tested against.

Decide where failed provider calls are logged before go-live. Check which service writes errors for the badge call (the LMS logs, the Credentials logs, or a worker's logs), and whether a failed call is retried or dropped. Then assign who reads those logs, how often they do so, and how a learner who completed the course but received no badge is found and reissued. Test the failure path on purpose using a sandbox provider account or a deliberately invalid credential. A failure nobody can see is a common reason learners report missing badges long after the course ended.

Settle what happens to completions recorded before the integration is switched on. Confirm whether the feature can issue badges for past completions, whether it only applies to completions after the switch date, and whether your release provides a command or batch process for backfilling. Each option changes the audit trail. A backfill issues badges to learners who finished months earlier, while a forward-only switch leaves earlier completers without a record unless you issue those credentials through a separate process. Agree the rule with the business owner, document the cut-off date, and rehearse the chosen approach on a copy of the learner data.

The first decision is whether each course gets its own badge template or whether several courses in a program share grouped templates. This choice sets how many provider records you maintain. One template per course means one record per course on the provider side, each with its own name, criteria, description and image. Grouped templates mean one record can cover a set of courses or a program-level award. Confirm how Credly and Accredible each name and structure templates, groups and badge classes, along with any limits on each, against current provider documentation before you draft the mapping. The terminology differs between providers, and the mapping table should use the names each provider actually uses.

Mapping and testing effort follow directly from this choice. Per-course templates make the mapping one to one: each course completion event maps to one template identifier. The table grows with every course, but each row is simple, and each new course needs one new entry and one test. Grouped templates reduce the number of entries, but they require a rule that decides when a learner qualifies for the group, such as completing a defined set of courses. That rule must be tested with partial progress, repeated attempts and learners who re-enroll. Decide early whether the grouping logic lives in the LMS, in the Credentials service or in the provider. A rule split across systems is the hardest to test and the easiest to break when one side changes.

The audience should guide the provider choice for each badge set. If badges are meant to be shared with employers or professional networks, the provider's public verification and sharing features matter more than internal consistency. If the main audience is an internal workforce or an academic group, check how each provider handles the same learner earning badges from several programs, and whether the learner's record stays consistent across them. Revision rules also need a decision before launch. When course content changes, decide whether badges already issued remain valid as awarded, whether a new template version applies only to future awards, and whether any earlier badges will be reissued. Changing a template name or criteria after learners hold badges creates confusion, so write these rules into the design first.

Ownership after launch needs a named owner. Assign one person or team to make template changes, one approver to sign off on them, and a change log that records what changed and why. Templates are often edited in the provider interface by staff who do not work on the platform, so access should match the service accounts and provider roles set up during the build. Each template or mapping change should be checked against a test learner record before it goes live. DeployOpen can plan this as part of a fixed-scope build or provide it as ongoing support under a retainer. The written scope should state who handles template edits, mapping changes and provider account changes after go-live.

Badge issuing is hard to undo cleanly once learners hold certificates with the wrong name, course or template, so the test plan should be agreed before the production switch is flipped. The core idea is to run the full path from course completion to a claimable badge in a non-production setting, using a provider sandbox or test group where one exists, and to record what each check proved. Availability of a sandbox or test group differs by vendor and plan, so confirm it with Credly and with Accredible before you design the rest of the plan, and confirm whether their test environments use separate API credentials, separate issuer or group identifiers, and separate badge templates from production.

Build dedicated test courses in a non-production Open edX instance, ideally one that mirrors the production LMS and Credentials configuration. Each course should map to one badge template or group so that a failure points at a single mapping. Create test learner accounts with distinct names and email addresses that are clearly synthetic, and never use real learner records in a sandbox. Give the test learners a mix of roles and enrollment paths, such as a standard enrollment, a verified enrollment if your site uses one, and an audit-only enrollment, so you can confirm which paths trigger issuance and which do not.

Check template selection, field values and claim delivery for every test course. For template selection, confirm that each completion lands on the intended badge and not a neighboring one. For field values, compare the learner name, course title, issue date, description and any criteria text in the badge against the source data in the LMS and Credentials, and confirm that the claim email or claim link reaches the test inbox with the correct recipient. Verify that the badge can be claimed or viewed and that its public or shared link behaves as your policy requires. Record the vendor-side identifiers for each issued badge so you can trace it back during support.

Run a repeat-completion test on the same learner and course, then a re-enrollment test if your course allows it. The expected result is that no second badge is issued, or that the behavior matches the rule you agreed, such as updating a single record. Test a learner who completes two courses that share a badge group to confirm the group logic. If the provider supports revocation, expiry or correction, run those tests too: revoke a test badge, correct a field where the provider allows edits, and confirm what the learner sees afterward. Where the provider does not support revocation through the integration, document the manual process your team will use instead and who approves it.

Finish with a written sign-off before production. The sign-off should list each test case, the result, the evidence (screenshots, identifiers, logs), the tester and the approver, and the known limitations that remain. Include the rollback or pause procedure for the integration, and confirm that production credentials, template identifiers and group identifiers are changed deliberately rather than copied from the test setup. Plan a short monitored period after go-live in which the first real completions are checked against the same criteria. Decisions about who signs off, and whether any test must be repeated after an Open edX or provider upgrade, should be made in advance.