Subscribe to a plan

In the platform, organizations do not subscribe directly to products.
Instead, they subscribe to plans, which define:

Which product is enabled (PCI, VRMS, Penetration, etc.)

What features are included (e.g. number of IPs, scanners, limits)

There are two types of plans:

Normal Plans

Open Plans

Both plan types follow the same validation rules and partner restrictions.

Plan Types

Normal Plans

Normal plans are predefined plans where all features are configured in advance.

When to use Normal Plans

Use Normal Plans when:

You sell fixed packages (e.g. 5 IPs, 10 IPs, 50 IPs)

Your pricing model is standardized

You do not need per-organization customization

How they work

Features (e.g. number_of_ips) are defined on the plan

When an organization is subscribed:

The subscription copies the plan’s features

The organization inherits these limits

The organization cannot override these features during subscription

Open Plans

Available on: v5.4.3

Open plans are flexible plans designed for partners who need on-demand features per organization.

Instead of defining features on the plan, features are provided during subscription.

When to use Open Plans

Use Open Plans when:

You sell usage-based or custom allocations

Each organization may have different limits

You want to avoid creating many similar plans

The problem that Open Plans Solve

Some partners sell custom limits per customer, for example:

Organization A → 10 IPs

Organization B → 3 IPs

Organization C → N IPs

Creating one plan per variation would be impractical.

How Open Plans work

The plan defines:

Product type

Billing behavior

Features are passed as parameters when subscribing an organization

The subscription stores the provided features

Subscription Example:

POST /v2/organizations/{id}/subscribe
{
  "plan": "pci-open",
  "features": {
    "number_of_ips": { limit: 5 }
  }
}

Partner Plan Restrictions

Regardless of plan type (Normal or Open), all subscriptions are validated against the partner’s limits.

Partner-Level Limits

Each partner has a Partner Plan that defines their total available capacity, for example:

💡

Partner Plan:

number_of_ips: 100

This represents the maximum number of IPs the partner can allocate across all organizations.

Validation Rules

The system enforces the following rules:

A partner cannot allocate more features than they own

The total assigned features across all organizations must not exceed partner limits

Validation applies to:

Normal Plans (predefined features)

Open Plans (custom features passed at subscription time)

Summary

#	Normal Plan	Open Plan
Features defined on plan
Features passed as subscription
Custom per Organization
Parent limit validation
Best For:	Fixes packages	Flexible / usage-based

`interval`

Defines the renewal or expiration interval of the subscription.

Accepted values:

none

monthly

yearly

Specifies how the subscription duration is calculated.

monthly: the subscription expires one month after the start_date, unless a custom end_date is provided.

yearly: the subscription expires one year after the start_date, unless a custom end_date is provided.

none: the subscription does not use a predefined billing interval. This can be used for custom or manually managed subscriptions.

Notes for none:

You may provide a custom end_date if you want the subscription to expire on a specific date.

You may also leave end_date empty to create a subscription that does not expire.

`start_date`

Defines when the subscription becomes active and from which date its duration starts being calculated.

If not provided, the current datetime is used.

For monthly and yearly subscriptions, the system uses start_date to calculate the default end_date.

For none, start_date defines when the subscription starts, even if no expiration date is set.

`end_date`

Defines the date and time when the subscription expires.

This field is automatically calculated when interval is monthly or yearly, based on the start_date, unless a custom end_date is provided.

Behavior by interval:

monthly: automatically set to one month after start_date

yearly: automatically set to one year after start_date

none: can be:

a custom expiration date, or

empty, for subscriptions that do not expire

Request

Authorization

Bearer Token

Provide your bearer token in the

Authorization

header when making requests to protected resources.

Example:

Authorization: Bearer ********************

API Key

Add parameter in header

x-api-key

Example:

x-api-key: ********************

Path Params

Query Params

Body Params application/json

Example

{
    "plan": "string",
    "interval": "none",
    "start_date": "2019-08-24",
    "end_date": "2019-08-24",
    "features": {
        "number_of_ips": {
            "limit": 10
        },
        "rescan": {
            "active": true,
            "unlimited": false,
            "num_of_rescans": 10,
            "unit": "day",
            "when_run": "always"
        },
        "ai_remediator": {
            "active": true
        }
    }
}

Request Code Samples

Shell

JavaScript

Java

Swift

PHP

Python

HTTP

Objective-C

Ruby

OCaml

Dart

Plan Types#

Normal Plans#

How they work#

Open Plans#

The problem that Open Plans Solve#

How Open Plans work#

Partner Plan Restrictions#

Partner-Level Limits#

Validation Rules#

Summary#

Subscribe Endpoint Params#

interval#

start_date#

end_date#

Request

Request Code Samples

Responses

Plan Types

Normal Plans

How they work

Open Plans

The problem that Open Plans Solve

How Open Plans work

Partner Plan Restrictions

Partner-Level Limits

Validation Rules

Summary

Subscribe Endpoint Params

`interval`

`start_date`

`end_date`