Plans & Quotas

Plan Overview

The table below compares all three plans across quotas and feature availability. A value of -1 in the API means unlimited.

Checking Current Plan

Every tenant has a planfield that indicates which tier they're on. Retrieve the tenant to check the current plan.

GET/api/v1/tenants/:id🔒 Auth

Retrieve tenant details including the current plan.

RequestResponse

cURLJavaScriptPythonGoPHP

curl -X GET https://id.vyntech.com.au/api/v1/tenants/t_abc123 \ -H "Authorization: Bearer eyJhbGciOiJFZERTQSIs..."

Retrieving Plan Details

Fetch all available plans with their quotas and feature flags. Use this to display plan comparisons in your UI or to programmatically check limits before creating resources.

GET/api/v1/plans🔒 Auth

List all plans with their quotas and feature availability.

RequestResponse

cURLJavaScriptPythonGoPHP

curl -X GET https://id.vyntech.com.au/api/v1/plans \ -H "Authorization: Bearer eyJhbGciOiJFZERTQSIs..."

Quota Enforcement

Quotas are enforced at creation time. When a tenant attempts to exceed a limit — for example, creating user #51 on the Free plan — the API returns 402 Payment Required with a message indicating which quota was hit and the current plan.

Existing resources are never deleted or disabled when a quota is reached. The tenant simply cannot create new resources of that type until they upgrade or delete existing ones.

Example: Quota Exceeded Response

When POST /api/v1/users is called on a Free plan tenant that already has 50 users:

{
  "error": "quota_exceeded",
  "message": "User limit reached. Your plan (free) allows a maximum of 50 users.",
  "quota": "max_users",
  "limit": 50,
  "current": 50,
  "plan": "free",
  "upgrade_url": "https://id.vyntech.com.au/billing/upgrade"
}

Feature Gating

Features not available on a tenant's plan return 403 Forbidden with a message indicating the feature requires a higher plan. This is distinct from permission-based 403s — the error body includes a feature_required field.

For example, calling PATCH /api/v1/settings with a risk_engine configuration on a Free plan tenant:

{
  "error": "feature_not_available",
  "message": "The risk_engine feature is not available on your plan (free). Upgrade to Pro or Enterprise to access this feature.",
  "feature_required": "risk_engine",
  "plan": "free",
  "minimum_plan": "pro",
  "upgrade_url": "https://id.vyntech.com.au/billing/upgrade"
}

Upgrading Plans

Plan changes are managed via the admin panel or by contacting sales. The API does not allow self-service plan changes — this prevents abuse and ensures billing coordination.

• •Immediate effect: When a tenant is upgraded, new limits and features apply immediately. No restart or re-authentication required.
• •No data loss on downgrade: If a tenant is downgraded (e.g., Pro → Free), existing resources are never deleted. However, new creation is blocked until the tenant is within the new plan's limits.
• •Feature disablement: Features not available on the new plan (e.g., risk engine on Free) stop being enforced but configuration is preserved. Re-upgrading restores previous settings.

Handling Quota Errors in Your App

Your application should gracefully handle 402responses by detecting the quota error and showing an upgrade prompt instead of a generic error message. Here's a pattern for each language:

POST/api/v1/users🔒 Auth

Example: creating a user with quota error handling.

RequestResponse

cURLJavaScriptPythonGoPHP

# Check the HTTP status code in your script STATUS=$(curl -s -o /tmp/response.json -w "%{http_code}" \ -X POST https://id.vyntech.com.au/api/v1/users \ -H "Authorization: Bearer eyJhbGciOiJFZERTQSIs..." \ -H "Content-Type: application/json" \ -d '{"email": "new@example.com", "password": "SecurePass1!"}') if [ "$STATUS" = "402" ]; then echo "Quota exceeded:" cat /tmp/response.json | jq '.message' echo "Upgrade at: $(cat /tmp/response.json | jq -r '.upgrade_url')" fi

Best Practices

What's Next