Rate Limits & PlansCopy Anchor Link

PayzCore enforces rate limits at two levels: burst limits to prevent abuse and daily plan-based limits tied to your subscription. Understanding both is essential for building reliable integrations.

PlansCopy Anchor Link

New accounts start on the Free plan. Project and wallet limits are enforced at creation time — if you downgrade from Pro to Free, existing projects and wallets continue to work, but you cannot create new ones until you are below the Free limit.

Burst Rate LimitsCopy Anchor Link

Burst limits protect against accidental loops, runaway scripts, and abuse. They operate on short sliding windows.

Per-API-key limitCopy Anchor Link

Every request authenticated with x-api-key counts against this limit. When exceeded, the API returns HTTP 429:

{
  "error": "Rate limit exceeded. Try again later."
}

With response headers (these are sent on the 429 response only):

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1739975400

Per-IP limitCopy Anchor Link

Unauthenticated endpoints (login, registration, health check) are rate-limited by IP address.

Other burst limitsCopy Anchor Link

These limits apply to the dashboard authentication flow, not to the project API.

Daily Plan LimitsCopy Anchor Link

Daily limits are tied to the project owner's plan. If you own multiple projects, all API calls across all your projects share the same daily quota.

API calls per dayCopy Anchor Link

Every successful API call (POST, GET) to /v1/* endpoints counts against this limit, with one exception:

GET /v1/config does not count against your daily API call limit. This endpoint returns your project's available networks and tokens. It is exempt so that plugins and integrations can fetch configuration freely without consuming your quota.

Webhooks per dayCopy Anchor Link

Each queued payment.partial, payment.expired and payment.cancelled webhook counts once against this limit (retries of the same webhook do not count again). payment.completed and payment.overpaid are exempt: they are always sent and do not use your quota, so you never miss a paid order.

Telegram notifications per dayCopy Anchor Link

Each Telegram notification sent to your linked account counts against this limit.

When daily limits are exceededCopy Anchor Link

When you hit your daily API call limit, the API returns HTTP 429 with a specific set of headers:

{
  "error": "Daily API call limit exceeded. Upgrade your plan for unlimited access.",
  "limit": 500,
  "plan": "free"
}

Response headers:

X-RateLimit-Limit: 500
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1740009600
X-RateLimit-Daily: true

The X-RateLimit-Daily: true header distinguishes a daily limit from a burst limit. This is important for your retry logic:

• Burst limit (X-RateLimit-Daily absent): Wait a few seconds and retry
• Daily limit (X-RateLimit-Daily: true): Do not retry until after midnight UTC

When the daily webhook limit is exceeded, further payment.partial, payment.expired and payment.cancelled webhooks that day are skipped (marked skipped in the webhook logs, not sent later). payment.completed and payment.overpaid are still sent. Use GET /v1/payments?updated_after=… to catch up on skipped events.

Daily Counter ResetCopy Anchor Link

All daily counters reset at midnight UTC (00:00:00 UTC). The X-RateLimit-Reset header in a daily limit response contains the Unix timestamp of the next midnight UTC.

Counters are tracked per user, not per project. If you own three projects, the API calls from all three projects count toward your single daily quota.

Rate Limit HeadersCopy Anchor Link

Rate limit headers are sent only on 429 responses. Successful responses (2xx) do not carry them, so you cannot read your remaining quota from normal responses.

The 429 Payment capacity exceeded response (pool + micro_amount mode) has no rate limit headers.

Requests with an unknown API key are also limited per client IP (30 per minute). After that, the API returns 429 with { "error": "Too many invalid API key attempts. Try again later." } and a Retry-After header (seconds) instead of 401.

The SDKs expose X-RateLimit-Reset as retryAfter / retry_after / getRetryAfter(). It is the same absolute Unix timestamp, not a number of seconds.

Checking Your Remaining QuotaCopy Anchor Link

Your daily usage (API calls, webhooks, Telegram notifications) is shown on the Dashboard page (plan usage card). Keep a simple client-side counter if you need to throttle before you hit the limit.

Admin Custom OverridesCopy Anchor Link

Account administrators can set custom limits for individual users that override the plan defaults. Custom overrides are set per-field, so an admin can increase your API call limit without changing your webhook limit.

Overridable fields:

• Maximum projects
• Maximum wallets
• Maximum payment links
• API calls per day
• Webhooks per day
• Telegram notifications per day

If a custom override is set, it takes precedence over the plan default. If it is removed, the plan default applies again.

Custom overrides are visible in the admin panel but not exposed to end users via API. If you need higher limits, contact your account administrator.

Upgrading Your PlanCopy Anchor Link

To increase your limits, upgrade to the Pro plan:

1. Log in to the dashboard at app.payzcore.com
2. Navigate to Billing in the sidebar
3. Select your preferred network (TRC20, BEP20, etc.)
4. Choose USDT or USDC and send the subscription amount to the displayed address (USDC is available on BEP20, ERC20, Polygon and Arbitrum, not on TRC20)
5. Your plan upgrades automatically once the payment is confirmed on-chain

Pro plan benefits take effect immediately upon payment confirmation. Daily counters for the current day are not reset — the new higher limit simply replaces the old one.

Best PracticesCopy Anchor Link

1. Cache responses where possible. If you poll GET /v1/payments/:id for status, use reasonable intervals (every 30-60 seconds, not every second).

2. Use webhooks instead of polling. Webhooks notify you when a payment status changes, eliminating the need for constant polling and saving API calls.

3. Implement exponential backoff. When you receive a 429 response, back off exponentially rather than retrying immediately.

4. Respect X-RateLimit-Reset on 429. It is an absolute Unix timestamp; wait until then before retrying.

5. Use GET /v1/config freely. This endpoint is exempt from daily limits, so plugins can call it on every admin page load without concern.

6. Batch operations where possible. Creating one payment with proper metadata is better than creating multiple test payments.

7. Separate environments. Use different projects (and API keys) for development and production to avoid development traffic consuming your production quota.