Management API guide
How to use our API to create keys on demand
Create and deliver license keys after a successful sale, without handling them by hand.
By System Locker 6 min read
A few manual sales are easy to handle from the developer portal. But, once keys need to go out after every checkout or upon issuing a Discord command, manual creation turns into a delay for your customer and another task for you. Our second iteration of the Management API allows you to programmatically create keys.
Here's the process: your checkout or bot confirms an event, your server asks System Locker for a key, and your server gives that key to the customer. This guide shows the request, the credential it needs, and the details that prevent duplicate keys when a payment provider retries a webhook.
Copy this tutorial and its code examples as plain text for an AI assistant or a clarifying question.
Run the request from your server
A Management API credential can create keys, reset HWIDs, and perform any other action covered by its scopes. Keep it in a server-side environment variable, a checkout backend, a private automation service, or a Discord bot&emdash;anywhere that's under your control is a suitable place for it.
Do not put this credential in a desktop application, a mobile app, browser JavaScript, or a public repository. Anything you ship to a customer can be inspected and copied. The customer-facing application should only ever contain the license key and necessary information that's not damaging in the hands of the public. Only your trusted service should use the Management API.
Create a credential with only the necessary scope
Open Systems in the developer portal, select the system you want to sell, and open API v2 Keys. Give the credential a name that tells you where it runs, such as checkout-production, then select only the keys.create scope. You can also set an expiration date for a short-lived integration.
Copy the credential when it appears and save it in your deployment's secret manager. The portal shows the complete value once. Credentials are tied to one System Locker system, so the same credential cannot create keys for another system on your account.
Keep the scope narrow. A service that only delivers purchases needs keys.create. Create another credential when a different integration needs to read, freeze, or delete keys. If a credential leaks, revoke that one credential instead of disrupting every integration.
Send the key-creation request
Send a JSON POST request to /api/v2/systems/{system}/keys. Replace YOUR_SYSTEM_ID with the ID from your Systems page and load the credential from your server environment. This example creates one 30-day key. Its clock starts when the customer first redeems it, not when the order is placed.
curl --request POST \
https://systemlocker.net/api/v2/systems/YOUR_SYSTEM_ID/keys \
--header "Authorization: Bearer $SYSTEM_LOCKER_API_KEY" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '{
"count": 1,
"notes": "Order #1842",
"expiry": {
"type": "after_redemption",
"seconds": 2592000
}
}'A successful request returns HTTP 201 and the created key or keys under data.keys.
{
"data": {
"keys": [
"YOUR_SYSTEM-7K2M-R8XQ-W5GH"
]
}
}Choose the right expiry
The expiry object controls how long a new key lasts. Send {"type":"perpetual"} for a key that does not expire. For a key that starts its duration on first use, send {"type":"after_redemption","seconds":2592000}. For an offer that ends at a fixed moment, use {"type":"at","at":"2027-01-15T00:00:00Z"}. Fixed timestamps must be UTC and end in Z.
Set free_trial to true when you need the standard free-trial behavior. You can create up to 100 keys in one request with count, though your plan's total key allowance still applies. The Management API reference lists the optional notes, format, reseller, and individual-trial fields.
Make payment retries safe
Payment providers retry webhooks. Networks also time out after a request has reached the server. Treat key creation as fulfillment work, not a fire-and-forget API call inside a request handler.
Record the payment provider's event or order ID before you create a key. When the API returns 201, store the key beside that record, then send the receipt. If you receive the same event again, return the saved result instead of creating another key. Use the notes field for the order number so you can find the key in the portal when you need to investigate a failed or timed-out job.
If the call times out after it leaves your server, do not blindly repeat it. Check the order record and look for its notes in the portal first. A second successful request creates a second valid key.
Deliver the key after success
Once you have a key in data.keys, store it with the order and show or email it to the customer. Then let your application authenticate that key with the same System Locker system. The API does not require a special provisioning mode, so you can use the same pattern for a storefront, a private admin tool, or a paid Discord command.
Ready to automate key delivery?
Create a scoped Management API credential for your system, then connect it to the trusted service that handles your sales.