Verify GST Numbers with Microsoft Power Automate

What the flow does

The pattern is the same one you would use to call any external REST API from Power Automate: a trigger starts the flow (a new SharePoint item, a new Dataverse row, a scheduled recurrence over a list of vendors), an HTTP action calls GET https://gstinapi.com/api/get-taxpayer-info/{gstin} with the GSTIN from the trigger and an X-API-Key header, a Parse JSON action turns the response into usable fields, a Condition checks the taxpayer's status, and a final action writes the result back into whatever system of record you use — Dataverse for model-driven apps, SharePoint for a simpler list.

The HTTP connector is premium — plan for it

This is the detail people miss until a flow breaks in production. Microsoft classifies the standard HTTP action as a premium connector. If your organisation's Power Automate licensing is the free tier bundled with Microsoft 365, flows using HTTP will fail or be blocked once the trial period on premium features ends, and building or running them typically requires a Power Automate per-user or per-flow plan (or a premium add-on) rather than the seeded licence. Confirm your organisation's current plan on Microsoft's licensing pages before you roll a GST-verification flow out beyond a personal test — it is a common reason a flow that worked for one builder fails when someone else in the tenant tries to run it.

Step 1: the HTTP action

Add an HTTP action and configure it as follows.

Method: GET
URI: https://gstinapi.com/api/get-taxpayer-info/@{triggerBody()?['gstin']}

Headers:
  X-API-Key: YOUR_API_KEY

The URI field accepts dynamic content, so replace the literal GSTIN with whatever field your trigger provides — a SharePoint column, a Dataverse field, or an item from a "For each" loop over a vendor list. Store the API key using an environment variable or a secure parameter where your tenant supports it, rather than pasting it directly into every flow that needs it, so a single rotation updates every flow at once.

Step 2: Parse JSON with a schema

Add a Parse JSON action immediately after the HTTP action, with the HTTP action's Body as its content. Generate the schema by pasting a sample response — call the endpoint once from a tool like Postman or the free GST search tool, copy the JSON body, and use Power Automate's "Generate from sample" option. This gives you typed dynamic content tokens for fields like legal name, trade name, status, registration date, and filing history in every step that follows, instead of manually parsing a string.

Step 3: a condition on status

Add a Condition action comparing the parsed status field to the literal text "Active". Route the "Yes" branch to whatever should happen automatically — updating a record, moving an approval forward — and the "No" branch to a review path, such as assigning a task to a compliance reviewer or posting a Teams message. This is the same active/cancelled/suspended distinction covered in more depth in our explainer on what a suspended GSTIN status means, which is worth reading before you decide how strict the "No" branch should be — cancelled and suspended carry different practical implications.

Step 4: write back to Dataverse or SharePoint

For Dataverse, use "Update a row" (or "Add a new row" on first verification) against the relevant table, mapping each Parse JSON output to the matching column. For SharePoint, use "Update item" against the list, mapping the same fields to list columns. Either way, write the verification timestamp alongside the result — a GSTIN's status can change later, and a stale "verified" flag with no date attached is not useful for an audit trail. If this flow feeds a broader onboarding process, our guide on integrating GST verification into an ERP workflow covers the same write-back pattern for systems beyond the Microsoft stack.

Handling errors and timeouts

Not every call succeeds cleanly. A malformed GSTIN, a taxpayer not found, or a transient timeout will return a non-success status from the HTTP action. Set the Parse JSON and Condition steps' "Configure run after" option to also run when the HTTP action has failed, timed out, or been skipped, then add a condition on the HTTP action's status code so failures route to a distinct "needs manual check" path instead of crashing the flow. This mirrors general good practice for calling any external API from an automation platform — see our guide on GST API error codes for what each failure response actually means.

Running this on a schedule instead of a trigger

Not every use case wants a per-record trigger. If you are re-verifying an existing vendor list rather than checking new records as they arrive, a Recurrence trigger paired with a "List rows" or "Get items" action and a "For each" loop is a better fit than firing the flow once per new item. Inside the loop, the same HTTP, Parse JSON, Condition, and write-back steps apply to each record in turn. The main design decision is how often to re-run the schedule: daily is reasonable for a small vendor list, while a large list with thousands of vendors may need to be split across multiple scheduled runs to stay within both the flow's execution time limits and your GST API credit budget for the period.

A canvas Power App can also call this same flow directly as an action, which is a common way to let a finance or procurement user trigger an on-demand GSTIN check from a custom form rather than waiting for a scheduled run or a SharePoint trigger to fire.

Monitoring failed runs

Power Automate's run history shows every execution, including which action failed and the raw error, but it is easy to let failed runs go unnoticed on a flow that otherwise runs quietly in the background. Add a parallel branch after the HTTP action, connected via "Configure run after" to trigger only when the HTTP action has failed, and have it post a summary to a Teams channel or send an email to whoever owns the flow. For a flow that verifies vendor or customer GSTINs as part of onboarding, a silent failure is worse than a visible one — it means a record moves forward unverified without anyone noticing, which defeats the purpose of adding the check at all. Our note on GST API error codes is a useful reference when deciding which failures are worth alerting on immediately versus queuing for a daily review.

Frequently asked questions