Understanding the integration of PadLock's "Get Key Online" feature and the WooCommerce Integration Kit

I am currently using PadLock v2025.2 and the corresponding version of the WC Kit and in the final stage before online Beta Testing. The Padlock Docs (2013 - 2017) touches on the subject but provides on insight into the WooCommerce Integration and the Kit documentation only addresses the "Online Activation" process which I understand; I also have a firm grasp on the workbooks.json configuration and have the Integration Kit properly configured and communicating with WooCommerce (initial setup complete. I have my subdomain, https://activation.mydomainname.me setup and the activation path to the Kit's folder.
Below is as sample snippet from workbooks.json.

Using the sample above, I understand the for online activation I would use - https://activation.mydomainname.me/getactivation/3 to actually "Activate" the app. What I do not understand is whether I would use the same structure with the "Get Key Online" feature, e.g., https://activation.mydomainname.me/getactivation/1 (or 2) to get the initial key to open the app in Trial Mode and if yes, does the "/3" activate based on the initial key or does it generate a new Key. Additionally, how does the user receive the new key for their records and/or future use?

**** Update ****

I attempted the Get Key Online using the real workbooks.json config:

and received the following error:

Method Not Allowed​

HTTP 405 (GET /getactivation/950)

Thanks in advance for your assistance.

The 405 first, because it is the quickest to clear: the /getactivation/... route only accepts POST. A browser address bar sends a GET, so the Kit correctly answers "405 Method Not Allowed". That is not a sign that your id or your config is wrong, it is simply the endpoint refusing a GET. Activation is performed by the compiled application, which sends a POST with the buyer's data, so test it from the app's activation dialog or from the demo, not by opening the URL by hand: https://demo.xlspadlock.com

Now the part that clears up the model. The number in /getactivation/{id} is the PRODUCT id, that is the top-level key under "products" in workbooks.json. In your file that is product 1, so the call is /getactivation/1. It is not the variation id. You do not choose the trial or the paid variation through the URL: the Kit reads the buyer's actual WooCommerce order, sees which variation they purchased, and applies that variation's rules (shownagscreen, keymaxdays, usehardwarelocking) from workbooks.json. So /getactivation/950 is being read as "product 950", which does not exist in your file, and it would fail for that reason once you are past the GET/405 point. Use the product id (1), and the Kit selects variation 950 from the order on its own.

That also answers the trial-versus-activation question: there is a single activation call, not a separate "get a trial key" step followed by an "activate" step. Whether the key that comes back is a trial key (nag on, time-limited, not hardware-locked) or a full key is decided entirely by the variation the customer ordered in WooCommerce. In other words, the trial-versus-paid choice lives in the order, not in the URL.

On how the key reaches the user: each successful call generates a fresh activation key on demand, server-side, from your product's master key (and the system id when the variation is hardware-locked), and hands it back to the application, which applies it automatically. The user does not copy down a key for the future. On any machine they simply enter their order token (their email plus their WooCommerce order number) and the app fetches and applies the right key, up to the activation count allowed for that order. The Kit records each activated system id against the order, which is how the maximum-activations limit is enforced.

Two things that commonly trip people up while testing: the request has to be a real POST from the app (or the demo), and the WooCommerce order you test with must be in the Completed status, otherwise activation is refused on purpose.

gdgsupport said:

Now the part that clears up the model. The number in /getactivation/{id} is the PRODUCT id, that is the top-level key under "products" in workbooks.json. In your file that is product 1, so the call is /getactivation/1. It is not the variation id. You do not choose the trial or the paid variation through the URL: the Kit reads the buyer's actual WooCommerce order, sees which variation they purchased, and applies that variation's rules (shownagscreen, keymaxdays, usehardwarelocking) from workbooks.json. So /getactivation/950 is being read as "product 950", which does not exist in your file, and it would fail for that reason once you are past the GET/405 point. Use the product id (1), and the Kit selects variation 950 from the order on its own.

Click to expand...

Thanks for your reply.

The variation ID "950" is the variation for Product ID 928 in the JSON file. I tried that and still received the same error. I went back and reread the Padlock Docs and the suggestion was to point to a PHP file and pass the id to the kit via that method. I got rid of the 404 and managed to get a 405 error. I have been trying to figure out catch the generateActivationKey function via that route and be able to capture/display the key so the user my copy it for their records and so they may actually open the application (which is the only way the app knows it is in trial mode). I obviously do not understand the order of operations for this functionality.

Any additional insight will be greatly appriciated.

Let us separate the pieces, because the "capture and display the key so the user can copy it" step is the part sending you down the wrong path.

The 405. The /getactivation/ route only accepts POST. Opening it in a browser is a GET, so the kit correctly answers 405 Method Not Allowed. That is expected, and it is not about your id or your JSON. Test activation from the compiled app's activation dialog or from the demo, not by typing the URL into a browser: https://demo.xlspadlock.com

The id in the URL. It is the product id, that is the top-level key under "products" in workbooks.json, not the variation id. Variation 950 lives under product 928, so the call is /getactivation/928, and the kit then reads the customer's actual WooCommerce order and applies the variation they bought. Pointing a browser at /getactivation/950 is read as "product 950", which does not exist, so it would fail for that reason too once you are past the GET/405 point.

Now the order of operations, which is the real fix. With the kit you do not fetch a key, show it to the user, and have them type it back. Online activation retrieves the key and applies it automatically. The activation dialog replaces the standard Enter Activation Key dialog: the user enters their token (their order email plus their WooCommerce order number), the app POSTs that to your server, the kit generates the key on the fly from your product's master key and returns it, and the app applies it and restarts. The user never copies a key. There is no wp-activation.php for you to write, and no generateActivationKey call for you to invoke or intercept from your own PHP: the kit does that internally on the POST. The custom-PHP route you are building is fighting the kit rather than using it, which is why you keep landing on 404 then 405.

So "Get Key Online" is not a separate "hand the user a trial key to paste" feature. It is this same online-activation exchange. Whether the key that comes back is a trial key (nag on, time-limited) or a full key is decided by the variation the customer ordered, not by a URL you build.

On the user having a record of the key: that is not part of the app flow and is not needed for them to run the app, because the app already holds the applied key. Their proof of purchase is simply their WooCommerce order. If you want visibility while testing, look at the kit's server side (its activation log and the order record), where each generated key and the system ids activated against the order are recorded, rather than trying to surface the key in the app UI.

If what you actually want is a free trial that opens with no order at all, that is the open-trial-key pattern from your other thread: a single non-hardware-locked trial key (nag on, keymaxdays set), which you can also deliver through the kit. It is still a key the app applies, not a value the user pastes.

One reminder while testing: the request has to be a real POST from the app or the demo, and the WooCommerce order you test with must be in the Completed status, otherwise activation is refused on purpose.

I need to further explain my workflow. Firstly, at this time I only offer "simple" products which are different versions of the same (or having slightly different VBA code) Excel Workbook. Secondly, I am legally required (Directive 2011/83/EU) offer a time/condition-based refund which requires being able to open the app with either a "provided" trial key or the ability to "Get Key Online" for the initial trial opening. I understand that I can include a "Read Me" test document in the packaged (Paquet Builder) installer but my desire is to streamline the User Experience by providing the relevant "Product-based" key automatically via email is virtually impossible. I need to have this process as fully automated (hands off) as possible. The customer is buying a specific product, not a variant, trial v. locked; the variants in workbooks.json control the initial and activated behavior.

My understanding of the v2025.2 PadLock documentation is that this is possible by setting up the Get Key Online (Website Interaction) URL = pathToActivationFolder/getactivation/prodID and setting up workbooks.json as shown in the snippet below (I configured there variant IDs as instructed in the kit's documentation but wonder if they actually need to exist because the Product type is actually "Simple" as previously described.

Using the first product ID below the Get Key URL = pathToActivationFolder/getactivation/926 and would default to the key configured in the variant (947) which is the trial key configuration, thereby activating it in Trial Mode. When the Buyer decides to activate their purchase (Online Activation) the pathToActivationFolder/getactivation/949/+ the System ID and the buyer enters their purchase token (email + purchaseID) automatically provided at purchase time.


As I understand the 2025.* documentation this is the default behavior. IF the Get Key feature is not configured the initial screen displays only the "Enter Key" field without the Get Online button.

The move to v2026.* compounds this problem because it defaults to asking for the Token, but to get access to the Key Entry screen one must click the Manual Activation button to gain access to the Key Entry screen and the included Get Key Online button (If configured). This may be fine for subscription-based products which have no trial period, but it is counter-intuitive for simple products and forces an additional step that is not apparent to the end user/buyer.

I hope this clarifies my initial question and I look forward to your guidance on this issue.