API

Getting a key

Create one under Settings → API access. Keys are prefixed ik_ and are shown once, at creation — we store only a hash, so we can't show it again. If it's lost, revoke it and make a new one.

Pass it as a bearer token on every request. Everything the dashboard enforces applies identically: plan limits, the duplicate-award guard, and pathway auto-awards.

List your badges

curl https://incredify.net/api/v1/badges \
  -H "Authorization: Bearer ik_your_key"

Issue a badge

curl -X POST https://incredify.net/api/v1/issue \
  -H "Authorization: Bearer ik_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "badge_id": "<badge uuid>",
    "recipient": { "email": "earner@example.edu", "name": "Jane Earner" }
  }'

# 201 -> { "assertion_id": "...", "claim_url": "...", "verify_url": "..." }

Optional fields: notify (boolean, default true) controls whether the recipient is emailed, and evidence accepts an array of up to 10 items with id/url, name, description, and narrative. File uploads aren't available over the API — attach files through single issuance in the dashboard.

Rate limits

Limits are per key, per minute. Exceeding one returns 429 Too Many Requests with a Retry-After header.

Exporting everything

GET /api/v1/export returns a full JSON export of your organization. It authenticates with your signed-in admin session, not an API key, and isn't plan-restricted. See Reporting and exports.

Public endpoints

These need no authentication at all — they're what makes a credential independently checkable:

• •GET /api/verify/<assertion-id> — verify a credential. 60 requests/minute per IP.
• •GET /api/assertions/<assertion-id>/credential.json — the raw Open Badges 3.0 credential.
• •GET /api/assertions/<assertion-id>/baked.png — the badge image with the credential embedded.
• •GET /issuers/<your-subdomain>/did.json — your published issuer identity and public keys.