Pricing and licensing
Decide whether your open-wa workflow needs a license key, then use the purchase or support path for current terms.
Use this page to decide whether your workflow needs a runtime license and where to choose the right license for it.
If you already know the gated method or runtime behavior you need, read Licensed features for the operational details before you buy.
First decision: do you need a key?
Start from the behavior your workflow needs. Method metadata marks methods as
restricted, insiders, or none; runtime-specific checks can add a
requirement to a particular path, and neither metadata nor a license makes an
unsupported method available in your deployed version.
| Feature | Decision | Next step |
|---|---|---|
| Your workflow only uses methods marked `none` | That method is not marked as license-gated by the current schema. Check the deployed version and any runtime-specific checks for the exact behavior you need. | Use the method in your deployed version and review the method reference for that release. |
| Your workflow calls a `restricted` method | The method metadata marks this behavior as Restricted. | Choose Restricted in the license form, then validate the purchased key against the host account and session you will run. |
| Your workflow calls an `insiders` method | The method metadata marks this behavior as Insiders. | Choose Insiders in the license form, then try the exact method in your connected session after configuring the purchased key. |
| You are unsure which method an integration calls | The integration name does not determine its licence requirement. | Check the integration path and the exact method or runtime behavior it calls, then use the applicable method metadata and runtime caveats. |
Use-case and license matrix
Use this matrix to separate runtime license requirements from upstream feature availability. A working host account and a method present in your deployed release are still required. The purchase buttons below select the relevant tier in the license form.
| Feature | Runtime licence requirement | Runtime qualification | Validate before relying on it | Purchase route |
|---|---|---|---|---|
| Read chats or send to an existing contact | The current method metadata marks the ordinary chat/read path `none`. | Requires a connected session and the normal API authentication setup. | Check the exact method in the reference for your deployed version. | No license is indicated for methods marked `none`. |
| Send a message to a number that is not already a contact | The runtime client reports that this special path needs a Restricted or Premium license, although `sendText` itself is marked `none` in method metadata. | This additional check applies to the unknown-number path; ordinary sends to existing contacts do not use it. | Confirm the actual runtime license status and test the path in the same session and release. | |
| Stories, status, buttons, lists, profile lookup, or profile pictures | Insiders applies to the methods currently marked `insiders`; check each exact method. | The method must exist in the deployed API catalog and be supported by the host account. | Check the method tier and availability for your deployed version, then call the exact feature. | |
| Create or join groups | Restricted applies to methods currently marked `restricted`. | The host account must be able to perform the group operation. | Test the exact group method with the production session and key. | |
| MCP, webhooks, Chatwoot, Node-RED, or a plugin | Follows the underlying methods the integration calls; the wrapper has no separate tier. | Integration availability and license eligibility are separate checks. | List or document the methods the integration will invoke, then test those methods. | Choose a license after checking the underlying methods. |
Current gated methods
The current licensed-feature page lists these gated methods. Treat this as a buying checklist, not a promise that every past or future build uses the same mapping.
| Feature | License tier | Methods listed in the current docs |
|---|---|---|
| Restricted | `restricted` | `createGroup`, `joinGroupViaLink`, and `joinGroup` |
| Insiders | `insiders` | `getNumberProfile`, `checkNumberStatus`, `getOrder`, status and story methods, button and list message methods, starred message access, and profile picture methods listed on the licensed-feature page. |
What a license key changes at runtime
You provide the key at launch
Supply the key through runtime config or the Easy API / CLI --license-key
option.
The runtime checks the key
When the host account context is available, the runtime sends the key to the validation service. It classifies the result before it marks the client ready.
The gated method still needs testing
A valid key is not a substitute for testing. Confirm the exact restricted or insiders method works in the same session and deployment you plan to run.
Integration buyers
Integrations do not need a separate license just because they are integrations. The license decision follows the behavior the integration calls.
| Feature | License question | Buyer action |
|---|---|---|
| Webhooks | Does the webhook only receive normal runtime events, or does the workflow also call a gated method? | If it only receives ungated events, decide from the underlying method list. If it calls restricted or insiders behavior, buy for that gated behavior. |
| Chatwoot | Which open-wa methods does the Chatwoot bridge need for your support workflow? | Buy only if the bridge depends on restricted or insiders methods in your real workflow. |
| Node-RED | Which Easy API methods do your Node-RED nodes call? | Match those methods to the licensed-feature metadata before buying. |
| MCP | Which Easy API tools will the MCP client execute? | MCP exposes Easy API methods as tools, so the same method-level license decision applies. |
| Plugin SDK | Which methods or runtime behavior does the plugin call after it loads? | A plugin wrapper does not decide the tier. The called behavior does. |
Team and organization buying
For team or organization questions, review the current offer at checkout and use the project support paths for terms it does not explain. The docs do not define multi-seat terms, per-developer scope, customer deployment scope, transfer rules, or support service levels.
If the purchase has multiple users, accounts, environments, or customer deployments, do not assume its scope. If the current offer does not answer your purchase question, use Discord or the paid support links in the project README.
Before you buy
| Feature | Check | Why it matters |
|---|---|---|
| Exact method or behavior | Name the restricted or insiders method your workflow depends on. | The current licensing guidance is method-level, not page-name-level. |
| Runtime session | Know which host account and session will run the workflow. | The licensed-feature docs tell readers to validate against the real host-account context. |
| Deployment path | Know whether the workflow runs through Easy API, custom code, MCP, Chatwoot, Node-RED, webhooks, or a plugin. | The wrapper can change the setup steps, but the license decision still follows the gated behavior. |
| Buying scope | For team or organization use, confirm unanswered scope questions through purchase or support. | The local sources do not publish team-seat or organization-license terms. |
Buy or verify first
Frequently asked questions
Where are the prices?+-
Can I decide from an integration name like webhooks, Chatwoot, Node-RED, MCP, or plugin SDK?+-
What if I need team or organization licensing?+-
What should I read before buying?+-
Was this helpful?
Your answer includes the page path and docs version.