---
title: "Use no-code tools with the REST API"
description: "Configure reviewed REST issuance in Zapier, Make or n8n, with private credentials, explicit result checks and honest retry/history limits."
slug: "/docs/v1/guides/no-code"
section: "Webhooks and integrations"
order: 79
audience: "all"
level: "intermediate"
last_updated: "2026-10-18"
version: "v1"
related: ["/docs/v1/api/create-license","/docs/v1/api/idempotency","/docs/v1/guides/manual-issuance"]
draft: false
---
Use an optional no-code HTTP action for a reviewed licensing request, not as a shortcut around purchase verification or durable duplicate handling.

## What you will learn

- Map one real REST create request into Zapier, Make and n8n.
- Keep credentials in a private connection and check the complete result.
- Hold uncertain operations instead of silently repeating a mutation.

## Prerequisites

- Complete the [Sandbox quickstart](/docs/v1/start/quickstart).
- Create a [product plan](/docs/v1/start/glossary#product-plan) and a Sandbox [developer API key](/docs/v1/start/glossary#developer-api-key) scoped to its [product](/docs/v1/start/glossary#product) with [licenses](/docs/v1/start/glossary#license):write.
- Use an existing tool account/instance whose credential, history and retention controls you have reviewed.
- Have a verified order or authorized manual request and a durable private operation record.
- Read [idempotency limits](/docs/v1/api/idempotency) before enabling any automatic workflow.

No Zapier, Make or n8n account is required to use [KDPika Licensing](/docs/v1/start/glossary#kdpika-licensing). These are optional tools chosen and operated by the [developer](/docs/v1/start/glossary#developer). This guide does not install another runtime on shared PHP hosting. If you want no external automation service, use the [PHP batch/backend pattern](/docs/v1/guides/manual-issuance) on infrastructure you control.

## Choose a safe scope

Start with a single operator-approved Sandbox issuance. The operator verifies the order, reserves its stable order-line operation once in a private ledger, then runs the HTTP action once. The private operation record must survive workflow retries, crashes, tool-history deletion and API replay-window expiry.

For unattended purchase fulfillment, you also need authenticated provider input, atomic durable effect reservation, serialized work, encrypted key [delivery](/docs/v1/start/glossary#delivery) and reconciliation after unknown results. A public catch-hook URL, an ordinary spreadsheet lookup or a workflow's success badge does not establish those properties. If your tool/configuration cannot satisfy them, keep it operator-reviewed or call your own reviewed fulfillment backend; do not present direct no-code issuance as safe exactly-once billing automation.

The licensing API does not validate a Stripe/Paddle/Gumroad order for you. Use a properly authenticated provider connector or verify the provider event/API result upstream. Never trust a browser-submitted paid=true field, a checkout return URL or an unsigned [webhook](/docs/v1/start/glossary#webhook) as purchase proof.

## Shared request and result settings

The complete settings reference below is contract-tested against the actual isolated Sandbox API for each tool profile. It is not an importable vendor workflow, marketplace connector or proof that a tool account was executed. Its explicit placeholders must be replaced with saved product/plan/order/recipient values.

```json
{
  "format": "KDPika no-code HTTP settings reference; not a vendor workflow import",
  "version": 1,
  "request": {
    "method": "POST",
    "url": "https://licensing.kdpika.com/api/v1/licenses",
    "credential": {
      "header": "Authorization",
      "scheme": "Bearer",
      "secret_source": "The selected tool's private credential connection",
      "required_scope": "licenses:write"
    },
    "headers": {
      "Accept": "application/json",
      "Content-Type": "application/json",
      "Idempotency-Key": "YOUR_WORKSPACE_STORE_ORDER_LINE_ID"
    },
    "body": {
      "product_id": "YOUR_PRODUCT_ID",
      "plan_id": "YOUR_PLAN_ID",
      "customer": {
        "email": "buyer@example.invalid",
        "name": "Demo Buyer"
      }
    }
  },
  "success_checks": {
    "http_status": 201,
    "success": true,
    "required_license_fields": ["id", "license_key", "expires_at", "environment"],
    "environment": "sandbox"
  },
  "safety": {
    "automatic_mutation_retry": false,
    "redirects": false,
    "verify_tls": true,
    "persist_intent_before_request": true,
    "unknown_result_action": "HOLD_FOR_REVIEW",
    "plaintext_key_in_public_history": false,
    "provider_event_verification": "Required upstream; an incoming webhook URL is not authentication"
  },
  "tools": [
    {
      "id": "zapier",
      "action": "API by Zapier: API Request",
      "credential_location": "Static Headers (API key) connection, Authorization: Bearer YOUR_DEVELOPER_API_KEY",
      "body_mode": "Valid JSON object",
      "reference": "https://help.zapier.com/hc/en-us/articles/44391650357005-Send-API-requests-in-Zap-workflows"
    },
    {
      "id": "make",
      "action": "HTTP Version 4: Make a request",
      "credential_location": "API key keychain, Authorization header with Bearer prefix",
      "body_mode": "application/JSON with Data structure",
      "reference": "https://apps.make.com/http"
    },
    {
      "id": "n8n",
      "action": "HTTP Request",
      "credential_location": "Generic Credential Type: Header Auth, Authorization: Bearer YOUR_DEVELOPER_API_KEY",
      "body_mode": "JSON: Using JSON",
      "reference": "https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest"
    }
  ]
}
```

| Setting | Value |
| --- | --- |
| Method | POST |
| URL | https://licensing.kdpika.com/api/v1/licenses |
| Authorization | Bearer developer API key, injected by the private credential connection |
| Accept and content type | application/json |
| Idempotency-Key | Stable [organization](/docs/v1/start/glossary#organization)/store/order-line reference, 8–190 characters, no buyer personal data |
| Request fields | product_id, plan_id, [customer](/docs/v1/start/glossary#customer).email and optional customer.name |
| Accepted result | HTTP 201, success=true, nonempty license.id/key and expected license.environment=sandbox |
| Unknown/error result | Hold the operation; do not automatically repeat create or renew |

The key already fixes the product and environment. X-Environment cannot turn a [Live](/docs/v1/start/glossary#live) management key into Sandbox. The create endpoint does not accept an arbitrary expires_at, a store price override or a plan-change action. A product slug/ID is not a [public App ID](/docs/v1/start/glossary#public-app-id). Use saved mappings rather than accepting a buyer-supplied target plan.

## Prepare the durable record

1. Record your verified store account, environment, order and order-line identity.
2. Resolve the intended product/plan from a private allowlisted mapping.
3. Verify the recipient email and any required consent for your delivery workflow.
4. Save the exact normalized request body and stable [idempotency key](/docs/v1/start/glossary#idempotency-key).
5. Reserve that operation so a second worker/operator cannot run it concurrently.
6. Mark the operation IN_FLIGHT before the HTTP step.
7. On explicit accepted success, save the key in a private encrypted outbox and mark DONE.
8. On a timeout, transport failure, malformed response, environment mismatch or HTTP error, mark HOLD_FOR_REVIEW.

Expected result: a completed operation is not run again and an unknown outcome is not treated as no license created. A lookup-then-create sequence in two parallel workflow runs is not an atomic reservation. Use a reviewed transactional backend if the tool cannot enforce it. The [tested PHP tool](/docs/v1/guides/manual-issuance) demonstrates why an intent must persist before a network call.

## Zapier

![Zapier procedure: review and reserve one order line, use API by Zapier with private credentials, accept only the expected 201, and hold uncertain results without replay.](/docs/diagrams/p8-no-code-zapier.svg)

Zapier procedure: review and reserve one order line, use API by Zapier with private credentials, accept only the expected 201, and hold uncertain results without replay.

### Configure credentials

1. In Apps, add an API by Zapier connection.
2. Select Static Headers (API key).
3. Store Authorization with the value Bearer followed by your Sandbox developer key in that private connection.
4. Restrict Domain filter to licensing.kdpika.com.
5. Give the connection a clear Sandbox/product label.

Expected result: the secret is connection-managed rather than pasted into an ordinary action's public configuration. Do not use the public-key endpoint as an authentication test; it succeeds without a developer key. Use a known scoped license GET with a read-scoped key only if you intentionally need a credential test. See the [official connection instructions](https://help.zapier.com/hc/en-us/articles/44391660158733-How-to-get-started-with-API-by-Zapier).

### Configure the request

1. Add API by Zapier and choose API Request.
2. Select the private connection above.
3. Set Method to POST and URL to the exact shared create URL.
4. Add Accept and Content-Type as application/json, plus the saved Idempotency-Key.
5. Put the shared request body in Body and map only approved values.
6. Validate the resulting JSON after mapping; quotes in a buyer name must not corrupt the body.
7. Keep the request under operator review and prevent automatic replay/retry of mutations.
8. Run Test step once for a new synthetic order and inspect the explicit 201/body/environment.
9. Persist the secure outbox and DONE outcome before sending the saved key privately.

Expected result: the create response includes a license ID/key and request_id. A step test itself can create a license; pressing it again is not a harmless preview. Prefer connection-managed API by Zapier over storing secrets as plain Webhooks by Zapier step fields. The editor fields are described in the [official API Request instructions](https://help.zapier.com/hc/en-us/articles/44391650357005-Send-API-requests-in-Zap-workflows).

Do not use a polling trigger to list KDPika licenses/customers: v1 has no such list endpoint. Do not enable a workflow auto-replay policy for create/renew merely because the tool offers one. If a tool plan does not let you constrain replay and protect returned key history, use your own fulfillment backend instead of direct production issuance.

## Make

![Make procedure: review and reserve one order line, use HTTP Version 4 with a private API-key keychain, accept the expected result and hold incomplete or uncertain runs.](/docs/diagrams/p8-no-code-make.svg)

Make procedure: review and reserve one order line, use HTTP Version 4 with a private API-key keychain, accept the expected result and hold incomplete or uncertain runs.

### Configure the HTTP action

1. Use HTTP Version 4 and choose Make a request.
2. Select API key authentication and create a private keychain for the Authorization header, including its Bearer prefix.
3. Set URL to the shared create URL and Method to POST.
4. Add Accept and the saved Idempotency-Key in Headers; keep authentication in the credential field.
5. Select application/JSON as Body content type.
6. Use Data structure for the nested customer object and map only approved product/plan/recipient fields.
7. Set Parse response to Yes.
8. Leave pagination off and do not configure redirecting destinations.
9. Configure failure handling to stop and hold the operation, not resend an uncertain mutation.
10. Run once for a new approved synthetic order, then inspect the expected 201/body/environment.

Expected result: JSON mapping preserves its nested customer fields and the returned key goes only to your reviewed private outbox. The [official HTTP module guide](https://apps.make.com/http) documents these settings. A filtered scenario or sequential processing setting alone is not a durable unique order reservation.

### Handle incomplete or retried runs

1. Save HOLD_FOR_REVIEW when the HTTP result is not an explicit accepted success.
2. Inspect the existing operation, request_id and current license/dashboard record before resuming.
3. Do not automatically resolve/retry an incomplete create or additive renew execution.
4. If the platform automatically retries a category of failure and you cannot safely prevent it for this path, send the request to your own durable fulfillment backend rather than directly to the licensing mutation.

Expected result: the tool's [incomplete-execution workflow](https://help.make.com/incomplete-executions) does not become a duplicate-issuance mechanism. A stored error record is not proof the upstream API did nothing. Keep credentials and returned customer/key data out of shared scenario screenshots and broadly accessible history.

## n8n

![n8n procedure: review and reserve one order line, use HTTP Request with Header Auth, keep mutation Retry On Fail off and route uncertain results to a held review record.](/docs/diagrams/p8-no-code-n8n.svg)

n8n procedure: review and reserve one order line, use HTTP Request with Header Auth, keep mutation Retry On Fail off and route uncertain results to a held review record.

### Configure credentials and HTTP

1. Use an existing reviewed n8n instance/account; this guide does not ask you to install Node or Docker on shared hosting.
2. Create a Header Auth credential with header Authorization and the private Bearer developer-key value.
3. Add an HTTP Request node using Generic Credential Type and select that credential.
4. Set Method to POST and URL to the shared create URL.
5. Enable Send Headers and add Accept, Content-Type and the saved Idempotency-Key.
6. Enable Send Body, choose JSON and Using JSON, and map the approved nested body.
7. Enable Include Response Headers and Status so the 201 can be checked explicitly.
8. Keep Ignore SSL Issues off, Redirects off and Pagination off.
9. Keep Retry On Fail off for create/renew; route a failed or uncertain result to your held review process.
10. Execute once for a fresh approved Sandbox order, then inspect status, success and license.environment.
11. Save the secure key outbox and DONE outcome before any separate key-delivery effect.

Expected result: the key is stored in a credential, not workflow JSON, and the HTTP response is not treated as success solely because a node continued. Use the [official HTTP Request settings](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest) and [HTTP credential guide](https://docs.n8n.io/integrations/builtin/credentials/httprequest/). If Never Error is enabled for explicit routing, check the HTTP status yourself; its output still does not prove a successful license creation.

Review execution-data retention and visibility using your [workflow settings](https://docs.n8n.io/build/manage-workflows/configure-workflow-settings.md). Disable unnecessary successful-execution/manual progress retention where appropriate, but do not claim a retention toggle encrypts the returned key or makes email delivery exactly once. Your credential access, execution storage, backups and outbox still need protection.

## Other supported operations

| Goal | Supported operation | Safety boundary |
| --- | --- | --- |
| Inspect a known license | GET /api/v1/licenses/{license} | Requires licenses:read and a known owned ID; not a list/search endpoint |
| Temporary payment investigation | POST /api/v1/licenses/{license}/suspend | Requires licenses:write and an authorized current-state decision |
| Restore suspended access | POST /api/v1/licenses/{license}/restore | Expiry/state rules apply; old tokens may require reactivation |
| Add an approved paid duration | POST /api/v1/licenses/{license}/renew with integer days | Additive, not idempotent; hold uncertain results instead of retrying |
| Final revoke | POST /api/v1/licenses/{license}/revoke | Terminal; not a generic refund API or reversible switch |
| Release all [devices](/docs/v1/start/glossary#device) | POST /api/v1/licenses/{license}/reset-devices | Requires devices:write; does not reset lifetime [activation count](/docs/v1/start/glossary#activation-count) |

Only configure these with their full [API reference](/docs/v1/api/conventions) and verified ownership/state checks. There is no v1 endpoint to charge/refund a store payment, change a license's plan in place, recover its original key or create a buyer-team directory. Do not send a management key from the buyer's browser to a webhook action.

## Test and verification boundary

This guide's exact HTTP settings are exercised against the actual isolated Sandbox create/[activation](/docs/v1/start/glossary#activation) API for all three tool profiles. The contract tests cover an explicit create, an identical replay with the same saved body/key, missing credentials and absent idempotency. They are not execution in a connected Zapier, Make or n8n account: no accounts or credentials for those optional services were provided. The procedure diagrams describe verified editor/API settings from official documentation, not fabricated account screenshots.

Before enabling a workflow in your own account, test one approved synthetic order, the same order delivered twice, a changed mapping under the same ID, a paused worker/restart, a lost response and a retained key resend. Confirm one durable business effect and zero blind retry on uncertainty. If your workflow cannot meet those checks, keep it manual or use the tested backend pattern.

## Expected result

Your selected tool sends the documented API request using a private scoped credential and checks the actual returned state. Unknown outcomes remain held for review, optional tool data exposure is understood, and no unsupported automatic purchase-verification or exactly-once guarantee is implied.

## Common mistakes

- Treating an unguessable catch-hook URL as authentication of a payment provider.
- Pasting a developer key into ordinary workflow JSON, a shared screenshot or a buyer application.
- Using a new Idempotency-Key every time a failed action is replayed.
- Sending keys by email before saving the original creation result securely.
- Assuming a workflow's dedupe filter protects against concurrent or post-expiration API requests.

## Security notes

Optional automation services can see submitted customer data and the complete key returned by create; a private credential connection protects authentication storage, not every response/history copy. Review access, retention, backups and your processor obligations before using real customer data. Do not publish keys in an action output, chat message, public table or link. If you require all fulfillment/key data to remain on your hosting, do not use an external no-code service for this step.

## Troubleshooting

| Symptom | Cause | Action |
| --- | --- | --- |
| INVALID_API_KEY or FORBIDDEN | Wrong/revoked credential, product/environment or missing [scope](/docs/v1/start/glossary#scope) | Correct the private connection; do not paste the key into an error ticket |
| INVALID_REQUEST on create | Missing stable header, wrong nested JSON or invalid recipient | Compare the exact saved request with the create reference |
| IDEMPOTENCY_CONFLICT | Same saved identity with changed decoded request/order | Stop and reconcile the mapping; do not bypass with a new key |
| Duplicate license or extra renewal days | Retry, parallel worker or API replay-window assumption | Stop automation and inspect the durable order/effect ledger |
| Tool says successful but key delivery is absent | HTTP action and email are separate effects | Check the saved secure outbox; never issue again merely to resend |
| Workflow history contains a complete key | Response data was retained by the tool | Restrict/purge under your policy and move issuance to your backend if controls are insufficient |

## Next steps

Use [manual issuance and durable key delivery](/docs/v1/guides/manual-issuance) to understand the transaction/recovery boundary, then review the [licensing recipes](/docs/v1/guides/recipes) before adding commercial lifecycle actions.

## Related

- [Create license reference](/docs/v1/api/create-license)
- [Idempotency limits](/docs/v1/api/idempotency)
- [Developer data protection](/docs/v1/security/developer-data-protection)