Databricks Community

fflory · a week ago

Following up on the trust-tier mechanics iyashk-DB explained in this thread (https://community.databricks.com/t5/generative-ai/foundation-models-api-blocked-quot-databricks-set-...) and this one (https://community.databricks.com/t5/generative-ai/enable-foundation-model-apis-for-aws-marketplace-t...😞 every resold third-party model serving endpoint in my workspace returns a "Databricks-set rate limit of 0", while open-weight endpoints in the same workspace work fine. Those threads identify this as a TRIAL_VERIFIED trust-tier hold, lifted by promotion to PAYABLE_VERIFIED.

Setup: Databricks on AWS, self-serve AWS Marketplace pay-as-you-go subscription, Premium pricing tier, us-east-1, Unity Catalog enabled, identity federation enabled, serverless compute. The account was created well over a month ago, past the "few business days" auto-promotion window. I have no support contract, which is why I'm posting here rather than opening a case.

Error (from both the Playground and the REST API):

{"error_code":"PERMISSION_DENIED","message":"PERMISSION_DENIED: The endpoint is temporarily disabled due to a Databricks-set rate limit of 0."}

What I've verified (all probes used the same OAuth token and workspace, within the same minute):

┌─────────────────────────────────────────────────────────────────────┬─────────────────────┐
│ Endpoint │ Result │
├─────────────────────────────────────────────────────────────────────┼─────────────────────┤
│ databricks-claude-sonnet-5, databricks-claude-opus-5 │ 403 rate limit of 0 │
├─────────────────────────────────────────────────────────────────────┼─────────────────────┤
│ databricks-gpt-5-6-terra, databricks-glm-5-2 │ 403 rate limit of 0 │
├─────────────────────────────────────────────────────────────────────┼─────────────────────┤
│ databricks-gpt-oss-120b, databricks-gpt-oss-20b │ 200 │
├─────────────────────────────────────────────────────────────────────┼─────────────────────┤
│ databricks-qwen35-122b-a10b, databricks-qwen3-next-80b-a3b-instruct │ 200 │
└─────────────────────────────────────────────────────────────────────┴─────────────────────┘

The blocked endpoints all report READY, and their AI Gateway configs carry no rate limit. The hold is imposed above the endpoint, which matches the trust-tier explanation.

What I've tried to get promoted: I emailed Support twice asking explicitly for promotion to PAYABLE_VERIFIED, citing both threads above. Both times the case was closed with a form reply that repeated the referral to this forum and didn't address the promotion request. There's also no in-product chat option on this account. My first AWS Marketplace invoice has also been paid (2026-09-03), and the block is unchanged a month later. So: how does an account in this position (Premium PAYG, no support contract, past the auto-promotion window) actually request or trigger the PAYABLE_VERIFIED promotion? Is there a self-service action, or does a Databricks employee need to act on a forum post like this one?

Separately: I also tried routing around the block with my own Anthropic API key via an external model serving endpoint (provider anthropic). Creating the endpoint worked, but the outbound call failed with 401 CUSTOMER_UNAUTHORIZED: Access to api.anthropic.com is denied because of serverless network policy. That's a second, account-level serverless-egress control (documented elsewhere as an Enterprise-tier feature), independent of the rate-limit-of-0 block. Is it the same gate as the trust-tier hold, or a separate one? And if separate, can it be lifted independently, for example with a serverless network policy allowlist entry?

Happy to share account/workspace IDs, exact timestamps, or repro steps by DM if someone from Databricks needs them.

DoTA · a week ago

Hi, some notes on how I would separate your two questions.

1. The rate limit of 0 and the 401 CUSTOMER_UNAUTHORIZED are almost certainly two independent gates, as you suspected. The first is imposed above the endpoint (your open-weight endpoints returning 200 in the same minute shows that). The second is the serverless network policy, whose error text names the policy explicitly, so lifting the trust tier would not change it by itself.

2. For the egress side, check Account Console > Security > Network policies and look at which policy your workspace is attached to (the default policy if you never assigned one). If it is in a restricted mode, the policy is where an allowed domain such as api.anthropic.com would be added. If that option is greyed out or missing on your tier, that would confirm the Enterprise-gating you read about. I have not verified which tier unlocks custom policies, so please check the current docs page for serverless egress control before relying on this.

3. For the promotion itself, I do not know of a self-service action. Since the Support cases were closed with a form reply, the options I would try are: (a) open the case against the account through the Account Console billing/support entry rather than a workspace so it routes to account and billing, and quote the exact string TRIAL_VERIFIED to PAYABLE_VERIFIED plus your paid Marketplace invoice date, (b) ask the AWS Marketplace seller contact on the listing, since the subscription was transacted there, and (c) tag a Databricks employee on this thread, since the threads you linked suggest that is who can act on the tier.

4. Meanwhile, to unblock work: databricks-gpt-oss-120b and the Qwen endpoints are open-weight and already return 200, so if you only need a working agent loop to develop against, point your dev environment there and keep the model name in a config value so swapping to a Claude or GPT endpoint later is a one-line change.

Hope this helps narrow it down.

fflory · Tuesday

Thanks, DoTA, this was helpful. Following up on each point:

Egress policy. I checked this. The account has a single network policy, default-policy, assigned to both workspaces. The Account Console has no page that shows it, so I read it through the account API instead. It is FULL_ACCESS (egress unrestricted), so there is no allow list to add api.anthropic.com to, and no tier restriction came up. That means the 401 on the custom Anthropic endpoint isn't network egress. My guess, untested, is that it comes from the same trust-tier hold as the 403s.

Promotion. I've now asked through several channels: support email, a resend to help@ and supportops@ (the first copy to sales@ bounced), and a request in the Account Console under Payments. I haven't had a substantive reply from Databricks yet. The earlier two support cases were closed with form replies pointing me back to the Community.

Where it stands. The first invoice was paid on 2026-09-03. A re-test on 2026-10-06, about a month after payment, still returns the same 403 on the resold Claude and GPT endpoints.

Could a Databricks employee tell me whether promotion to PAYABLE_VERIFIED is possible for this account type, and what I'd need to send? I can share account identifiers by DM.

anuj_lathi · Wednesday

Short answer: I'm not aware of any self-service action, in the workspace or the account console, that promotes an account's trust tier. That's a Databricks-side determination, so someone at Databricks has to act on it. The Anthropic 401 is a separate gate from the rate-limit-of-0 hold.

1. Getting the promotion actioned

Your diagnosis fits what you see. The blocked endpoints are READY, their AI Gateway configs have no limit, and the open-weight models answer 200 on the same token. The hold is applied above the endpoint, so nothing you change on the endpoint or in AI Gateway will lift it. Foundation Model API endpoints are system-provided and preconfigured per workspace [1], so you have no endpoint-level knob that would override it.

Since Support has closed two cases with a form reply, I'd stop emailing the same queue and go at it from other angles:

Make the case actionable. Collect your account ID (account console, dropdown next to your username, top right [2]), the workspace ID, and the AWS Marketplace subscription and invoice reference. A request that says "paid Marketplace customer, invoice settled, account ID X, requesting access to third-party hosted models" is much easier to route than a request that names an internal tier.
Use the commercial channel, not the technical one. You're paying through AWS Marketplace, so the contact-seller path on the Databricks Marketplace listing, or a Databricks sales/billing contact, reaches a different team than technical support. This is the route most likely to get someone with the authority to change the account's state.
Ask the forum thread's participants directly. If a Databricks employee already explained the tier mechanics in those threads, @-mention them in this thread with the account ID. The forum isn't an official request channel, so they may have to pass it to an internal team, but an employee can do that and I can't.
Take the account ID and invoice date to AWS. AWS Support or the Marketplace seller-contact flow can sometimes escalate to the ISV when the ISV's own queue doesn't respond.

2. The Anthropic 401 is a different gate

I'd treat these as two independent controls:

Symptom	Layer
`403 PERMISSION_DENIED … Databricks-set rate limit of 0`	Databricks-side hold on Databricks-hosted, resold third-party models
`401 CUSTOMER_UNAUTHORIZED … denied because of serverless network policy`	Your account's serverless egress policy blocking outbound traffic to `api.anthropic.com`

They have different status codes and different messages, and they're enforced in different places. The 401 names the serverless network policy explicitly, so it isn't a trust-tier symptom. Creating the external-model endpoint succeeded because that is just configuration. The failure happens when serverless compute tries to reach the external host.

Lifting it independently should be possible in principle. Account admins manage network policies in the account console, so check whether the policy attached to your workspace is in a restricted-access mode, and if it is, whether you can add api.anthropic.com as an allowed destination. If the console doesn't let you edit the policy on your tier, then the feature gating you read about is what's stopping you, and the only fix is a tier or entitlement change, which again goes through your Databricks account contact. I can't promise from here that egress allowlisting is available on your plan, so confirm that in the console first.

3. What I'd do next

Check the serverless network policy in the account console. If it's editable, add the Anthropic host. That unblocks your own-key path without waiting on anyone.
In parallel, send the account ID, invoice date, and Marketplace subscription details through the commercial/seller-contact path, and tag the Databricks employees in the earlier threads here.
Until one of those lands, route Claude/GPT workloads through the external model endpoint once egress works, and use the open-weight endpoints for everything else.

References

[1] Databricks Foundation Model APIs | Databricks on AWS — https://docs.databricks.com/aws/en/machine-learning/foundation-model-apis
[2] Manage your Databricks account | Databricks on AWS — https://docs.databricks.com/aws/en/admin/account-settings

Anuj Lathi
Solutions Engineer @ Databricks

orbitnotes · Saturday

Thanks @anuj_lathi, this is the first staff answer on the thread and it helps.

Network policy: I already checked this. The account has one account-level network policy, default-policy, and both workspaces use it. The Account Console doesn't have a page for it (the policy link 404s), so I read it with the CLI (databricks account network-policies get-network-policy-rpc). It's restriction_mode: FULL_ACCESS, which means outbound access is unrestricted and there's nothing to allowlist. So egress shouldn't be what blocks the custom Anthropic endpoint.

The 401 as a separate gate: that's useful to know. I'd assumed one promotion would clear both. The external-model endpoint returns 401 CUSTOMER_UNAUTHORIZED and egress is open, so what does that gate check? Is it the account's tier, an entitlement, or something on the endpoint itself? I'm happy to chase it as its own issue once the rate-limit hold is sorted.

Making the request actionable: the account ID, workspace ID, paid invoice number and date, and the Marketplace agreement ID went to help@databricks.com (cc supportops@) and through the Account Console on 2026-10-06. Nobody has replied yet, and this account has no support contract, so earlier cases were closed with a referral to this forum. The sales@ address on the Marketplace listing bounces outside mail, and the listing has no seller contact form.

So my main question: who at Databricks can approve a TRIAL_VERIFIED → PAYABLE_VERIFIED promotion for a pay-as-you-go account with no support contract, and could you pass this to them? I can DM you all the identifiers. @iyashk-DB, you described this hold in threads 160952 and 163757, so tagging you in case you can help.

anuj_lathi · 17 hours ago

Short answer: I'm a community peer, but I don't have any information on the approval POCs either or I can't approve a tier change or push this into an internal queue. Nothing in the product or documentation gives an account like yours a self-service way to trigger it. Also, with FULL_ACCESS on your network policy, I'd walk back my earlier confidence that the 401 is a clearly separate gate.

Who can approve the promotion

The only thing the earlier threads establish is that Databricks Sales or Support has to move the workspace to PAYABLE_VERIFIED [1]. They also say the promotion normally happens within a few business days but sometimes needs a manual bump from Databricks' side [2]. Neither thread names a team, queue, or form. I can't tell you a specific person who owns it, and I won't guess.

What I can do is help you frame the request so it reads as an account anomaly rather than a feature request:

Lead with the documented default, not the internal tier name. The Foundation Model API limits page says partner models default to Tier 1 quota (1M ITPM / 100K OTPM), "applied automatically... unless a model-specific provider-capacity exception applies" [3]. Your partner endpoints return a rate limit of 0 while the open models on the same token return 200. That contradicts the documented default, and it's a much easier thing for a triager to route.
Ask one Premium-specific question. The limits page says limits vary by workspace platform tier, and its partner-model tables are written for Enterprise-tier workspaces [3]. Ask them to confirm whether the Premium tier is a factor in your zero quota or whether it's purely an account-verification hold. Their answer will tell you whether promotion alone fixes this.
Use a different front door than the support queue. Two routes that don't depend on a support contract:
- the sales contact form at databricks.com/company/contact, since the Marketplace listing's sales address bounces
- an AWS Support case against the Marketplace subscription, asking AWS to contact the seller about an unresolved account-activation issue
Keep your identifiers out of public posts. Thread 163757 shows what that looks like. Send the account ID, workspace ID, invoice, and agreement ID only through private channels.

I'd also give the 2026-10-06 email a fixed window, say 5 business days. If nothing comes back, open the sales-form and AWS routes in parallel and reference the earlier email's timestamp in both.

The 401: separate gate or not?

I told you the 401 was a serverless egress policy matter because the message names the serverless network policy. You've now shown the account policy is FULL_ACCESS, so there is nothing for you to allowlist. That leaves three possibilities, and I can't distinguish them from the outside:

The policy actually enforced for that workspace isn't the one you read.
The denial is a Databricks-side control on your account that surfaces with the same message.
It's tied to the same account verification state as the rate-limit hold.

Treat "separate gate" as unproven. Two cheap probes will narrow it down.

Probe 1: serverless notebook, no key.

import requests
r = requests.get("https://api.anthropic.com/v1/models", timeout=10)
print(r.status_code, r.text[:300])

If egress really is open, you should get Anthropic's own response (a missing-API-key authentication error in Anthropic's JSON format), not a Databricks denial. If you get a Databricks-worded denial here, the block is at the compute or account level and not specific to the model serving path.

Probe 2: external model endpoint to a host you control. Create an external model endpoint with the `cust