Docs

GPORais API guide

The GPORais API answers one precise question: does this registry key, this OMA-URI or this policy name match a real Group Policy setting, and under what conditions? It is built for deployment scripts, audit tools and AI agents that must check a value before writing it to a fleet.

Every response states where the information comes from (Microsoft source, version) and how old the data is. The API never guesses: when it does not know, it says so.

API base URL: https://api.gporais.com — no sign-up needed to start.

Your first call in 30 seconds

The health endpoint is public. Paste the address into your browser, or run:

curl https://api.gporais.com/v1/health

{
  "status": "ok",
  "dataset": { "version": "6aa00495", "generatedAt": "2026-09-08T12:50:29Z" },
  "counts": { "parametres": 19446, "registrePairs": 33168 }
}

dataset is the part that matters: the version and date of the data the API is using. You will find it on every response.

Second call, still without any tool: open https://api.gporais.com/v1/setting/wuau-autoupdatecfg in your browser. You get the full record of a setting, as JSON.

Endpoints

Method	Path	Question it answers
`POST`	`/v1/resolve`	”Which setting is this registry key and value? Does it apply to my OS?”
`POST`	`/v1/csp`	”Which Group Policy and registry key match this Intune OMA-URI?”
`POST`	`/v1/search`	”Which setting has this name?”
`GET`	`/v1/setting/{slug}`	”Give me everything about this setting.”
`GET`	`/v1/health`	”Is the service up, and on which data?”

POST endpoints expect a JSON body with Content-Type: application/json. The lang field is en-US or fr-FR; it sets the language of the labels returned.

Recipe 1 — Check a registry key before you deploy it

This is the main use case. You have a registry path and a value name; you want to know which Group Policy setting they belong to and whether it applies to your Windows version.

PowerShell — build the body with ConvertTo-Json so you never escape backslashes by hand.

$body = @{
    key      = 'HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU'
    value    = 'NoAutoUpdate'
    lang     = 'en-US'
    targetOs = 'Windows 11 24H2'
} | ConvertTo-Json

$r = Invoke-RestMethod -Uri 'https://api.gporais.com/v1/resolve' -Method Post `
       -ContentType 'application/json; charset=utf-8' -Body $body

$r.result.compatibility.verdict          # supported
$r.result.matches | Select-Object slug, displayName

curl — inside a JSON body, each \ of the path is written \\.

curl -X POST 'https://api.gporais.com/v1/resolve' \
  -H 'Content-Type: application/json' \
  --data '{"key":"HKLM\\Software\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU","value":"NoAutoUpdate","lang":"en-US","targetOs":"Windows 11 24H2"}'

In Windows PowerShell 5.1, curl is an alias for Invoke-WebRequest. Type curl.exe to call the real curl, or use the PowerShell example above.

Python

import requests  # pip install requests

r = requests.post("https://api.gporais.com/v1/resolve", json={
    "key": r"HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU",
    "value": "NoAutoUpdate",
    "lang": "en-US",
    "targetOs": "Windows 11 24H2",
}, timeout=30)
r.raise_for_status()
data = r.json()
print(data["result"]["compatibility"]["verdict"])   # supported

Real response (abridged: the other fields of each setting are omitted):

{
  "query": {
    "key": "software\\policies\\microsoft\\windows\\windowsupdate\\au",
    "value": "noautoupdate",
    "lang": "en-US",
    "hive": "HKLM",
    "targetOs": "Windows 11 24H2"
  },
  "result": {
    "matches": [
      {
        "slug": "wuau-autoupdatecfg",
        "displayName": "Configure Automatic Updates",
        "class": "Machine",
        "registryKey": "Software\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU",
        "valueName": "NoAutoUpdate",
        "source": "windows",
        "csp": { "omaUri": "./Device/Vendor/MSFT/Policy/Config/Update/AllowAutoUpdate" }
      },
      { "slug": "icm-internetmanagement-restrictcommunication-2" }
    ],
    "compatibility": {
      "verdict": "supported",
      "reason": "target build 10.0.26100 (Windows 11 24H2) meets minimum 10.0.19041.1202",
      "targetBuild": "10.0.26100",
      "requiredBuild": "10.0.19041.1202"
    }
  },
  "confidence": "official",
  "provenance": { "source": "windows", "sourceVersion": "Windows 11 25H2",
                  "learnUrl": "https://learn.microsoft.com/…/policy-csp-update#allowautoupdate" },
  "dataset": { "version": "6aa00495", "generatedAt": "2026-09-08T12:50:29Z" },
  "warnings": [
    "The registry pair HKLM\\…\\au\\noautoupdate is written by 2 parameters: wuau-autoupdatecfg, icm-internetmanagement-restrictcommunication-2. Returning all matches and letting the agent choose."
  ]
}

Three things to read in this response:

query is the request as the API understood it: path normalised to lower case, HKLM hive extracted. Check it first when a result surprises you.
Two settings write the same registry value. The API does not choose for you: it returns both and says so in warnings. That is not an error; it is information your script must handle.
compatibility.verdict is supported: Windows 11 24H2 (build 10.0.26100) is above the documented minimum (10.0.19041.1202).

The hive is read from the path: HKLM\… and HKEY_LOCAL_MACHINE\… give the same result, the API normalises both to HKLM.

Recipe 2 — When the target OS is ambiguous

Drop the OS family and send only "targetOs": "22H2". The response:

"compatibility": {
  "verdict": "unknown",
  "reason": "…"
}

The reason lists the two candidates — Windows 10 (build 10.0.19045) and Windows 11 (build 10.0.22621) — and how to resolve the ambiguity.

This is the API’s founding rule: it never fills a gap with a guess. “22H2” exists on both Windows 10 and Windows 11, with two different builds; rather than betting, the API gives you both candidates. Send Windows 10 22H2, Windows 11 22H2, or a build number directly.

The four possible verdicts:

Verdict	Meaning
`supported`	The target build reaches the documented minimum.
`unsupported`	The target build is below the documented minimum.
`unverified`	Microsoft states a minimum, but without a usable build number.
`unknown`	The target OS is missing, unrecognised or ambiguous.

Recipe 3 — Start from an Intune OMA-URI

You manage devices with Intune and want the equivalent Group Policy and registry key:

$body = @{ omaUri = './Device/Vendor/MSFT/Policy/Config/Update/AllowAutoUpdate'; lang = 'en-US' } |
        ConvertTo-Json
$r = Invoke-RestMethod -Uri 'https://api.gporais.com/v1/csp' -Method Post `
       -ContentType 'application/json; charset=utf-8' -Body $body
$r.result.matches | Select-Object slug, registryKey, valueName

The real response returns wuau-autoupdatecfg with "confidence": "official": the mapping is stated by Microsoft, not inferred.

Recipe 4 — Find a setting by name

curl -X POST 'https://api.gporais.com/v1/search' \
  -H 'Content-Type: application/json' \
  --data '{"q":"DisableSearchHistory","lang":"en-US","limit":3}'

Real response: one result, search-disablesearchhistory.

Good to know: search is built for names, not sentences. It finds a technical name (DisableSearchHistory, NoAutoUpdate) or a few English keywords (automatic updates) very well. A full sentence returns few or no relevant results. For natural-language search, use the search bar on the website; in a script, pass the value or policy name.

Recipe 5 — Get the full record of a setting

The slug is the stable identifier of a setting; it is also the end of its address on gporais.com.

curl 'https://api.gporais.com/v1/setting/wuau-autoupdatecfg?lang=en-US'

Without ?lang=, the record is returned in English. The response contains result.setting: the path in the Group Policy console, the registry key and values, the configurable elements, the Intune mapping when one exists, and the supported Windows versions.

Recipe 6 — Check a list of keys in bulk

You have a CSV file of keys to check before a rollout. This script checks them one by one while respecting the anonymous rate limit (10 requests per minute):

# keys.csv :  key,value
#             HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU,NoAutoUpdate
$targetOs = 'Windows 11 24H2'

function Test-Key($key, $value) {
    $body = @{ key = $key; value = $value; lang = 'en-US'; targetOs = $targetOs } | ConvertTo-Json
    for ($attempt = 1; $attempt -le 2; $attempt++) {
        try {
            return Invoke-RestMethod -Uri 'https://api.gporais.com/v1/resolve' -Method Post `
                     -ContentType 'application/json; charset=utf-8' -Body $body
        } catch {
            if ($_.Exception.Response.StatusCode.value__ -ne 429 -or $attempt -eq 2) { throw }
            Write-Warning 'Rate limit reached: waiting one minute, then retrying.'
            Start-Sleep -Seconds 60
        }
    }
}

Import-Csv .\keys.csv | ForEach-Object {
    $r = Test-Key $_.key $_.value
    [pscustomobject]@{
        Key      = "$($_.key)\$($_.value)"
        Settings = ($r.result.matches.slug -join ', ')
        Verdict  = $r.result.compatibility.verdict
        Warnings = $r.warnings.Count
    }
    Start-Sleep -Seconds 7      # 10 requests per minute without a key
} | Format-Table -AutoSize

With an API key you can shorten the pause to one second (60 requests per minute). A key with no matching setting is not an error: result.matches is empty and result.reason explains why.

Reading a response: the envelope

Every response carries the same six top-level fields. That is what lets a script tell a proof from an inference and from uncertainty.

Field	What it guarantees
`query`	The normalised request the API actually evaluated.
`result`	The matches, the requested record, or a reason when nothing matches.
`confidence`	`official`: Microsoft states the mapping. `derived`: GPORais inferred it. `none`: no match — and `result.reason` says why.
`provenance`	The source, its version and the Microsoft Learn link when one exists.
`dataset`	Version and date of the data. This is your proof of freshness.
`warnings`	What the API noticed without deciding for you.

confidence: "none" is an answer, not an error. For about three settings out of four there is no Intune equivalent; saying so clearly, with the reason, is the service.

Limits to know before you automate

	Anonymous	With a key
Prefix	`/v1/`	`/k/v1/` + `X-API-Key` header
Rate	10 requests / minute per IP address	60 requests / minute per IP address
Sign-up	none	on request (see below)
Cost	free	free

What your script needs to account for:

Beyond the limit you get HTTP 429 until the one-minute window ends. That 429 has an empty body and no Retry-After header: wait a minute before resuming.
There is no remaining-requests counter. Responses carry X-GPORais-Tier (anonymous or key) and X-RateLimit-Limit (10 or 60), but nothing that counts down. Space your calls rather than waiting for the 429.
Blocking is not instantaneous. The host can take around ten seconds to enforce it, so a short burst may get through. Do not rely on it; the limit is the rule.
Search works on names, not natural language (see recipe 4).
About one setting in four has an Intune equivalent. For the others the API answers confidence: "none" with the reason.
The API does not redistribute Microsoft’s explanatory text: it serves facts (paths, values, OMA-URIs, versions) and a link to the source.
The API data can lag behind the website. Compare dataset.generatedAt with your freshness requirements; that is exactly why it is returned every time.
No service guarantee. Data is provided as is: verify before writing to a production fleet.

Errors

HTTP errors follow the “problem details” format of RFC 9457. Real example, a call under /k/v1/ without a key:

{
  "type": "urn:problem:gporais-api:unauthorized",
  "title": "Unauthorized",
  "status": 401,
  "detail": "API key missing or invalid."
}

Code	When	What to do
`401`	Key missing, invalid or revoked under `/k/v1/`	Check the `X-API-Key` header, or use `/v1/`.
`429`	Rate limit exceeded	Wait one minute. Empty body, no `Retry-After`.
`200` + `confidence: "none"`	No setting matches	Not an error: read `result.reason`.

An unknown slug, for example, does not return 404 but a 200 with:

"result": { "reason": "No setting matches slug this-slug-does-not-exist for en-US." },
"confidence": "none"

Getting a key

There is no self-service sign-up. Request a key through the contact details on the About page, describing your intended use. Then:

Invoke-RestMethod -Uri 'https://api.gporais.com/k/v1/resolve' -Method Post `
  -Headers @{ 'X-API-Key' = 'YOUR_KEY' } `
  -ContentType 'application/json; charset=utf-8' -Body $body

Same endpoints, /k/v1/ prefix instead of /v1/, and six times the rate. A key can be revoked in case of abuse. The health endpoint stays public on both prefixes.

Going further

The API reference details every field, the measured data coverage and the edge cases of compatibility checks. To show a GPORais record directly in your intranet or wiki, see Embed a record.

GPORais is an independent technical resource, neither affiliated with nor endorsed by Microsoft.