Enforcement of Azure Translator free tier F0 limit appears not to be enforced when using Power Automate Translator V3 connector

Question

Enforcement of Azure Translator free tier F0 limit appears not to be enforced when using Power Automate Translator V3 connector

Megan OConnor 65

Potential bug with Power Automate V3 Translator task.

I have an Azure Translator resource (standalone resource not in Foundry) on the Free (F0) pricing tier that I am testing in a Power Automate flow.

We are trying to capture when the resource has exhausted the 2M character monthly limit to be able to failover to another resource in a higher SKU.

However, it seems like at least for the Power Automate V3 translator task, the 2M free tier limit is not enforced.

We tested hitting the 2M character limit, and upon reaching this - it does block calls from direct calls using curl, etc as well as the demo feature in the Azure portal.

checking the network call from the Azure portal shows the same error from curl in cmd "{"error":{"code":401001,"message":"The request is not authorized because credentials are missing or invalid."}}"

In Power Automate, using the V2 translator task appears to properly show an issue once the connector attached to the resource with the exhausted limit is used.

However, the V3 Translator task allows translating to continue even after the 2M limit has been exhausted on our resource. And we have confirmed this with our metrics showing 2.57M+ translated characters as well as receiving the translated text in our flow output.

Figured this is likely a bug, and do not want to be back-billed later if we end up going past the free limit for our flows when that is not our intention.

Can provide additional details if needed.

Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator

2026-10-01T08:07:16.4733333+00:00

Hello @Megan OConnor ,

Following up to see if the following response helps

Thank you
Megan OConnor 65 Reputation points

2026-10-01T11:52:49.3533333+00:00

Yes thank you that was very helpful!

Answer accepted by question author

0 additional answers

Your answer

Karnam Venkata Rajeswari 5,340 Reputation points Microsoft External Staff Moderator

2026-10-01T08:07:16.4733333+00:00

Hello @Megan OConnor ,

Following up to see if the following response helps

Thank you
Megan OConnor 65 Reputation points

2026-10-01T11:52:49.3533333+00:00

Yes thank you that was very helpful!

Answer 1

Hi @Megan OConnor

Good testing, and I think two separate things are getting mixed together here, which changes the conclusion.

The 401001 you saw from curl and the portal demo isn't the quota error. It means the key or region header was wrong or missing. When an F0 resource actually runs out, Translator returns 403001, "the subscription has exceeded its free quota". So the direct calls weren't proving enforcement, they were failing for a different reason, which is why V3 kept working with its correctly configured connection.
The billing worry can be set aside. F0 has no overage billing at all. It's a hard limit, and once metering catches up, requests are rejected rather than charged. Because metering lags a bit, a small overshoot like your 2.57M can slip through, but it's never back-billed.
For your failover, key off the real signal. In the flow, add a parallel branch or a following action set to run after the V3 action fails, check the error output for 403001, and call the S1 resource there.
Even better, switch before the wall. Set an Azure Monitor metric alert on "Characters Translated" for the F0 resource at around 1.9M, and flip a variable or connection when it fires.
If the V3 connector still translates after a confirmed 403001 from direct calls, then it's worth a report with the flow run IDs. Until then, this looks like normal metering delay plus a test that didn't measure what it seemed to.

If this helped, please click Accept Answer so others building free tier failover can find it.

References: https://learn.microsoft.com/en-us/azure/ai-services/translator/service-limits https://learn.microsoft.com/en-us/azure/ai-services/translator/reference/v3-0-reference

Megan OConnor 65 Reputation points

2026-09-30T14:49:30.47+00:00

Hi @Rukshan edirisinghe ,

Thanks for your answer!

I agree and was expecting to get some sort of error message relating to quota usage and not an "unauthorized" message.

However, I am certain i was calling the api correctly and did follow that format from the v3 api reference.

I just tried with another new translate resource and it worked in calls and in the demo "try it" feature up until 2M, after which i started getting that same unauthorized message.

but not in the V3 power automate action for whatever reason still allowed further translations.

But that's good to hear from your second point that there should be no overage billing! that was my main concern.

Was wondering also if you happened to know of any documentation on any limits to the # of F0 resources allowed (like per subscription)? I could not find any.

It seems like there is a limit of 1 per region, at least when testing on my msdn subscription.

I was able to create 1 in eastus, 1 in eastus2, etc - but when trying to create a second in the same region get a validation error in the portal

"Operation failed. Only one free account is allowed for account type 'TextTranslation'. (Code: CanNotCreateMultipleFreeAccounts)" And this seems to be for subscription, as I got same error trying to create it in a fresh RG.

This just changes our strategy as our org uses a shared subscription, so if there is some documented subscription limit for the F0 resource we may not be able to use that at all if another team on the sub has already used it.

Thanks a bunch

Answer 2

Hello @Megan OConnor ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

Thank you for completing the additional test with a new Translator resource.

The documented response for an exhausted free quota is HTTP 403 with error code 403001. Error code 401000 is documented for missing or invalid credentials. Since the observed response is 401001 and the same configuration worked before reaching approximately 2 million characters, the result does not match either documented condition. This should therefore be treated as a possible error-mapping or quota-enforcement inconsistency rather than a confirmed authentication problem.

The V3 action continuing to return translations while REST, the portal test, and V2 no longer succeed is also unexpected. The V3 connector is currently in public preview and the available documentation does not describe a separate F0 allowance or quota-bypass behavior.

Regarding billing, the F0 tier includes 2 million characters per month and does not publish a per-character overage price. Automatic conversion to S1 billing would therefore not normally be expected

As a precaution, please open Cost Management > Cost analysis, filter by the affected resource ID, and group the results by Resource and Meter. This will confirm whether any activity is being recorded against another Translator or paid multi-service resource.

The CanNotCreateMultipleFreeAccounts validation is consistent with one F0 TextTranslation resource being allowed per subscription in the tested region. A different resource group does not bypass the restriction, while another region may allow a separate F0 resource.

This exact resource-count rule is not currently published on the Translator service-limits page. It should therefore be treated as observed service enforcement rather than a formally documented quota.

If an F0 resource was previously deleted, Manage deleted resources can be reviewed and the resource can be purged when recovery is not required. This is a cleanup check and is not a confirmed cause of the current validation error.

For a reliable failover design, please check if the following steps help-

Create separate F0 and S1 connections with predefined translation actions.
Maintain an application-side monthly character counter, including each target language.
Select an internal switch threshold below 2 million characters. A threshold such as 1.8 to 1.9 million can be used as an engineering buffer, but it is not an official service recommendation.
Fail over immediately for a confirmed 403001 response.
Retry 429xxx responses with controlled backoff because they represent request-limit conditions.
Treat 401xxx responses as authentication or unexpected-error conditions and log them for investigation instead of automatically routing to S1.
Configure an Azure Monitor metric alert for early warning.
Use Power Automate scopes and Run after settings to capture errors and control the fallback path.

The following references might be helpful , please check them out

Please let us know if the response was helpful

Thank you