$ feature / developer-api

Automate everything the dashboard does.

The SDK lives inside your shipped application and validates a license at runtime. The developer API is the other half: a REST surface at api.authforge.cc your backend calls to create, modify, and react to licenses server-to-server. The classic shape is "payment succeeds → create license → email the key; refund happens → revoke the license."

Bearer keys with scoped permissions

You mint API keys in the dashboard and send them as a Authorization: Bearer af_live_… header. Each key carries an explicit scope set, so a key used by a fulfillment worker can be limited to exactly what it needs:

• read:licenses / write:licenses
• read:apps / write:apps / admin:apps
• read:webhooks / write:webhooks
• read:logs

A wildcard (*) scope grants full access for trusted internal keys. Keys can be given an expiry and are swept automatically once they lapse.

REST CRUD that mirrors the dashboard

Licenses, apps, webhooks, and per-app/per-license variables are all manageable over /v1/* — create, list, get, update, delete — plus operational actions like resetting a license's HWID slots:

curl -X POST https://api.authforge.cc/v1/licenses \
  -H "Authorization: Bearer af_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "appId": "app_123", "maxHwidSlots": 2, "expiresAt": null }'

Rate limits and credit cost

API requests are rate-limited per key. Unlike SDK runtime validation, developer-API calls are management operations and do not consume validation credits — you can list, reconcile, and bulk-issue keys without burning your balance. Credits are spent on /auth/validate and heartbeats from the SDK, not on dashboard or API CRUD.