RPC error HTTP 403: Forbidden

Read the error field

On Triport a 403 means the key was accepted and the request was still refused, so changing the key will not help. The error field tells you which refusal it was, and the two need different responses.

tier_insufficient

This is the common one on gated categories. required_tier in the body and the X-Required-Tier header both name the lowest plan that can call the method, so your code can report something useful without a lookup. On Solana, for example, sendBundle and simulateTransaction start at Pro and DAS methods at Basic.

{
  "error": "tier_insufficient",
  "message": "Method 'sendBundle' requires pro tier or higher",
  "current_tier": "free",
  "required_tier": "pro",
  "method": "sendBundle",
  "category": "sol_send_bundle",
  "upgrade_url": "https://triport.io/upgrade/pro"
}

method_unknown

method_unknown is about the catalog, not your plan: no upgrade changes it. The usual causes are a typo, a method from another chain sent to this endpoint, or a write on a read-only network: sendBoc on TON is refused this way, for example. Compare against the method list for the network. A misspelled URL gives a different answer, 404.

Handle it in code

Treat a 403 as a configuration problem, not a transient one. A retry loop cannot change the plan or the catalog, so it only adds refused requests and hides the cause behind a backoff. Read error, log method and required_tier, and stop that code path. If one feature of your application needs a higher plan than the rest, check for tier_insufficient and turn that feature off with a clear message, so the rest keeps working.

A plan change applies to your existing key, so there is nothing to rotate after you upgrade. If the same request still answers 403 afterwards, compare current_tier in the body with the plan you expect. When they differ, the request is probably using a key from another account.

The same refusal on WebSocket

A WebSocket has no response body to read once it has opened, so a refused subscription arrives as close code 4003. It covers both tier_insufficient and method_unknown, and the close frame carries the same error string as the HTTP response. Log the reason along with the code. A client that only logs the code will reconnect and be refused again, and the loop looks like an unstable connection rather than a plan limit. For the separate case of too many streams, see close 4029.

If the 403 did not come from us

A 403 with an HTML body rather than JSON came from something in front of the API, such as a corporate proxy or a Cloudflare rule. Triport's refusals are JSON and carry X-Triport-Error. If that header is missing, check what sits between your client and the API before changing anything in your request.