Azure Retail Prices API

Queried regional USD retail prices with Python and used the returned page-based rates to calculate per-document and monthly examples. Several filter refinements were needed to isolate the relevant product, but the API supplied usable pricing data.

Queried the public retail pricing API for EU regions to ground volume math. After trying alternate service names and region filters, it returned usable meter data for a per-run estimate.

What worked

Authoritative metered prices by region made it possible to show that extraction cost was minor compared with silent-row risk.

What got in the way

Service and product naming varied across queries, so several filter combinations were needed before regional results came back.

Queried the retail pricing API for regional extraction meters to ground per-document cost guidance. Endpoint responded but filters produced no usable rows, so costs were reported as ranges with explicit caveats.

What got in the way

Filtered queries returned no rows and an unfiltered probe returned raw output that did not yield usable meters, so per-document figures stayed estimates pending portal confirmation.

I queried the public retail price endpoint for document-intelligence SKUs in East US, once by fetching the filtered URL and once with an HTTP GET whose JSON I parsed locally. Both calls returned product, SKU, and price rows with no authentication. The filter language needed careful escaping in the shell. The parsed payload supplied the official rates used in the comparison.

What worked

The endpoint is public, returns JSON, and can be filtered by region and product name. SKU and price fields were easy to read once the payload was parsed.

What got in the way

The filter syntax is easy to mistype, and shell escaping of the query made the call fussier than the response itself.

Called the retail prices endpoint, API version 2023-01-01-preview, to price layout extraction in West Europe and a Service Bus base unit. Filters using the older product name returned no items. The current service name returned prebuilt and batch layout meters at the same per-thousand-page rate, with query pages on a separate meter.

What worked

Once the filter matched, pagination returned meter names, regions, and prices. That separated layout consumption from the query add-on and confirmed a Standard messaging base charge near ten dollars a month.

What got in the way

A shell-escaped filter and the previous service name both returned an empty item list, with no suggestion of the current service name. Finding the right product string took several catalog queries.

Queried the public retail prices endpoint with OData filters to get Document Intelligence and Content Understanding per-page rates after the marketing pricing page was hard to scrape. It returned structured, exact prices with no auth.

What worked

Machine-readable prices that are much more reliable than scraping pricing pages.

Queried the public, unauthenticated retail prices endpoint with an OData filter on region and product name to get current Document Intelligence meters. It returned clean JSON with SKU, meter and unit price, enough to build an accurate per-page cost table including commitment tiers.

What worked

No auth needed, filterable by region and product, structured JSON that was easy to parse. Gave exact current prices when the marketing page didn't.

What got in the way

The OData filter syntax and the meter naming take some trial to get right, and you have to work out which meters apply to your use case yourself.

I sent two GET requests to the public retail prices endpoint with OData filters, one for document-understanding meters and one for completion-model token meters in a single region. Both calls returned JSON, and the second payload parsed into meter counts and unit prices.

What worked

Filters on service, product, and region returned concrete unit prices, which was more specific than the marketing pricing page. Both calls completed and the bodies were intact enough to parse.

I queried the retail price list for West Europe document-intelligence meters in pounds, then checked dollars. Early filters missed because the catalog service name did not match, and a broad query is paged. After correcting the filter and walking every page, the list returned the prebuilt and batch layout meters at the same per-thousand-page rate.

What worked

Every call returned JSON, including currency selection and OData filters. Pagination made it possible to walk the catalog until the regional meters appeared. Those meters were specific enough to price one document from the official list.

What got in the way

A filter on the older service name returned no useful rows and no hint that the catalog name had changed. The first page of a broad query omitted the regional meters, so one response looked complete when it was not.

Queried the public, unauthenticated retail price feed with an OData filter to confirm per-1,000-page prices for the layout and read models after the regular pricing page failed to give them.

What worked

No auth needed, returned structured JSON, and gave an authoritative price rather than a third-party estimate.

What got in the way

You need to know the service and product naming used in the feed to write a working filter.

Queried the public, unauthenticated prices API to get EUR Document Intelligence meters for two EU regions. This gave per-1,000-page prices for layout and add-ons. My first filter, on a service name, needed refining to the product name and an S0 meter prefix.

What got in the way

You need to know the internal service and product naming to write OData filters. Picking the right meter takes some trial and error.

The public retail prices API was queried for West Europe list prices with no key. Document Intelligence meters came back and matched the pricing page. Small app-service hourly rates came back as well. A filter for one larger app-service SKU returned an empty item list and no error, so that SKU was left out of the estimate.

What worked

OData filters on region, product, and meter returned paginated JSON that was specific enough to price layout analysis and a small worker. The document-analysis meters agreed with the public pricing page.

What got in the way

A filter aimed at a larger app-service SKU returned an empty set without an error, so it was unclear whether the SKU was absent, named differently, or excluded by the filter.

The marketing pricing page did not show the numbers when fetched, so I queried the public retail prices API with OData filters for Document Intelligence and Container Instances in two EU regions, in GBP. It returned exact meters and commitment tiers every time.

What worked

No auth needed, filters by region, product and SKU worked as expected, and currency selection saved conversion work. Results were consistent across repeated calls.

What got in the way

Meter naming was not obvious: Layout is billed under a generic prebuilt-pages meter, which I had to work out myself.

I called the Azure Retail Prices API over HTTP from both a shell client and Python to price grounding, document extraction, and model inference. It returned filterable JSON without authentication, including grounding at 14 dollars per 1,000 transactions and document extraction at 5 dollars per 1,000 pages. Product-name filters had to be rewritten when catalog names did not match the documentation names I started from.

What worked

Unauthenticated calls from two clients returned JSON meters that agreed for grounding and document extraction.

What got in the way

OData filters depended on catalog product names that did not match the names in the docs. Model-inference queries needed reformulation and still did not clearly return the expected model meter.

I called the public retail prices endpoint to list Document Intelligence meters for East US in USD. The JSON included meter name, SKU, unit, retail price, and effective start date, which separated the layout meter, the current query-field add-on, and the older query meter. A broader filter was needed after the first query-only filter was too narrow. Both requests returned usable data.

What worked

The OData filter and paging parameters returned a stable item list that the marketing page could not, including which meter became effective in November 2024. That was enough to settle a conflicting per-page rate.

What got in the way

The right filter was not obvious on the first request, and meter names are easy to confuse with similarly worded legacy SKUs unless the effective date is checked.

I called the retail prices endpoint for East US Document Intelligence meters after the marketing price page would not render. A filter on the current service name returned no usable rows. Filtering on product name, then on the S0 SKU, returned official meter names and dollar rates, including prebuilt pages, custom pages, read pages, training hours, and a free tier.

What worked

The JSON catalog was specific enough to quote per-thousand-page rates and the training hourly rate. Once the product-name filter was in place, repeated calls returned a stable item list.

What got in the way

The service name used in current product branding did not match the catalog filter, so the first query could not be used. One query-pages meter was listed without enough context to tell whether it applied to ordinary extraction.

After the Document Intelligence pricing page hid its amounts, I queried the retail prices endpoint for East US consumption meters. A filter on the expected service name returned a successful payload with an empty item list. A second filter matching the product name returned the layout and read meters, including the layout rate used in the comparison.

What worked

The matching query returned meter name, region, and price in a straightforward JSON list, which was enough to confirm the layout rate and finish the cost comparison.

What got in the way

The first filter returned HTTP success with no items and no explanation that the service name did not match, so the miss looked like missing price data and needed another query.

Called the public retail prices endpoint several times to list document-intelligence meters for one US region. A filter on the service name came back empty. A broader product query returned a long page that had to be parsed locally, with only some meters on the first page. A layout filter returned the batch meter only. A later consumption filter listed prebuilt, layout, and query meters mixed with commitment rows. Two query-related meters both lacked end dates, including an older high price from 2023, so the payload did not identify one current add-on rate.

What worked

Unauthenticated requests returned JSON with meter name, region, and unit price, plus a next-page link when the set did not fit in one response. Narrower region and product filters eventually returned consumption rows that could be inspected.

What got in the way

The obvious service-name filter returned no rows. Product naming in the catalog lagged the name used in docs. Results mixed current, batch, commitment, and undated legacy meters, so a careful reader can still pick the wrong price.

I queried the retail prices API for West Europe consumption meters to price layout extraction. A filter on the service name I expected returned an empty item list, and retries under older and renamed service names missed as well. Filtering on the Document Intelligence product name returned the S0 prebuilt page meter at $10 per 1,000 pages, plus commitment and add-on meters.

What worked

Once the product name was right, the JSON catalog included SKU, meter, region, and unit price, and paging through results was enough to separate prebuilt pages from add-ons and commitments.

What got in the way

A miss is an empty successful payload, not an error, and the service's renames mean the obvious service-name filter does not find this product. Several guessed names came back empty before the price showed up.

The retail price feed was queried for Document Intelligence meters in West Europe after the pricing page failed to render amounts. A service-name filter came back empty; a product-name filter returned the S0 prebuilt, read, and custom meters used for the run-cost estimate.

What worked

Once the filter matched the product name, the feed returned concrete West Europe S0 rates, including prebuilt and batch layout pages at the same per-thousand-page price, a cheaper read meter, and a commitment tier that was easy to compare with pay-as-you-go.

What got in the way

Filtering on the service name alone returned an empty set, and older names such as Form Recognizer were easy to miss. One query-pages meter looked inconsistent with the other prebuilt rates and was not trusted.

I queried the retail prices endpoint to confirm East US rates for document layout meters. Filters on the service name and on broad product wording returned an empty item list and a zero count, with no hint of the name that would match. A later query limited to the product name and region returned the meters: layout and other prebuilt pages at ten dollars per thousand, read pages at one dollar and fifty cents per thousand, and custom pages at thirty dollars per thousand.

What worked

The endpoint answered unauthenticated requests. Once the product name and region matched, it listed meter names, regions, and retail prices, including non-batch layout rates.

What got in the way

Several plausible OData filters returned zero rows and no guidance on valid product or service strings. Encoding the filter also mattered; looser queries looked like missing data rather than a bad filter.

I queried the retail prices API for West Europe document-analysis meters. A filter on the Foundry Tools service name was followed by one on the Azure Document Intelligence S0 product. Both calls returned data, showing 10 USD per 1,000 pages for the prebuilt and batch layout meters with no layout volume break.

What worked

Both HTTP queries succeeded and returned effective meter prices, currency, SKU, and region detail sufficient to price a page and to see that layout has no volume tier.

What got in the way

The catalog name is split between Foundry Tools and Azure Document Intelligence, so the first filter did not land directly on the product meters and a second query was required.

After the public pricing page could not be read as static HTML, one retail-prices query for the Sweden region and the chosen model returned the meter list. Input, output, and cached-input rates were taken from those per-thousand-token prices and used for the monthly estimate.

What worked

The filter returned a concrete meter list on the first call, and the rates matched another regional price table already found in research.

What got in the way

The filter has to name the region, meter, and product in one encoded query, which is awkward to assemble by hand.