How to Integrate a GST Verification API with SAP

There are two realistic ways to connect a GST verification API to SAP: direct ABAP consumption using cl_http_client or cl_web_http_client, or routing the call through SAP Cloud Integration (CPI) as middleware. Most SAP shops use the second option. This guide covers both, plus where the check actually belongs — vendor master creation and invoice verification in MIRO.

Two realistic ways to do this in SAP

"Integrate with SAP" covers a wide range of actual architectures, and the honest answer is that it depends heavily on your landscape. A pure ECC shop with no middleware might genuinely write ABAP that calls out directly. A modern S/4HANA landscape with SAP Integration Suite already in place will almost always prefer routing the call through CPI, both because it is where every other third-party integration already lives and because it keeps outbound HTTP calls, retries, and credential storage out of the ABAP stack entirely. Neither is "wrong" — the difference is mostly what your landscape already has.

Option 1: direct ABAP consumption

The classic approach uses cl_http_client, available in most supported NetWeaver releases. Newer systems can use cl_web_http_client, SAP's HTTP/2-capable successor with a somewhat cleaner API. Both work; the newer class is preferred where available.

DATA(lo_http_client) = cl_http_client=>create_by_url(
  url = |https://gstinapi.com/api/get-taxpayer-info/{ lv_gstin }|
).

lo_http_client->request->set_header_field(
  name  = 'X-API-Key'
  value = lv_api_key
).

lo_http_client->send( ).
lo_http_client->receive( ).

DATA(lv_response_body) = lo_http_client->response->get_cdata( ).
DATA(lv_status_code)   = lo_http_client->response->get_status( )-code.

lo_http_client->close( ).

With cl_web_http_client, the equivalent uses cl_web_http_client_manager to create the client and a slightly different request/response object model, but the shape of the call is the same: set the endpoint, add the header, send, read the status and body. Either way, you still need to deserialize the JSON response yourself — typically with /ui2/cl_json or a custom parser into an ABAP structure matching the response schema.

Option 2: CPI / Integration Suite as middleware

The more common pattern builds an integration flow in SAP Cloud Integration that receives a request from ABAP (via a lightweight proxy call, an IDoc, or a custom OData service) or runs on a schedule, calls the GST verification endpoint, and returns the parsed result back to SAP or writes it directly into a target system. A typical iFlow for this looks like:

1. Sender adapter (SOAP, OData, or a scheduled timer) receives or initiates the request with a GSTIN.
2. A Content Modifier sets the request headers, including X-API-Key read from a Secure Parameter or Credential Alias — never hardcoded in the iFlow.
3. An HTTP receiver adapter calls GET https://gstinapi.com/api/get-taxpayer-info/{gstin}.
4. A Message Mapping or Groovy script step maps the JSON response fields onto the target structure (an IDoc, an OData payload, or a database write).
5. A router step branches on the status field, similar to the condition logic in a Power Automate or Zapier flow, sending an alert message for anything other than Active.

CPI's built-in monitoring, retry configuration, and credential store handle most of the operational concerns that direct ABAP code would otherwise need to reimplement by hand — which is the main argument for this approach once an organisation already runs Integration Suite for anything else.

Wiring it into vendor master creation

Whichever integration path you choose, the highest-value checkpoint is vendor master creation. In S/4HANA, this means the Business Partner model; in classic ECC, the LFA1-based vendor master. A reasonable design triggers the GST verification call from a custom Business Add-In (BAdI) or enhancement point fired when a vendor's GSTIN field is populated or changed, writes the returned status and legal name onto custom fields on the vendor record, and either blocks the vendor for payment or routes it to a reviewer if the GSTIN comes back Cancelled, Suspended, or not found. This is the same "catch it before it becomes a payment problem" logic described in our guide on automating vendor GST verification in accounts payable, applied specifically to the SAP vendor master object.

Wiring it into MIRO invoice verification

A GSTIN that was Active when a vendor was onboarded is not guaranteed to still be Active months later — registrations do get cancelled or suspended. A periodic reconciliation job (rather than a hard, real-time block inside the MIRO transaction itself, which most teams find too disruptive) re-verifies vendor GSTINs on a schedule and flags any vendor whose status has changed since the last check, alongside invoices posted against that vendor in the same window. Some organisations additionally add a soft check at MIRO time — a warning message rather than a hard stop — for vendors whose GSTIN has not been re-verified within a defined period. Either design keeps the checked-at-onboarding assumption from quietly going stale.

Which approach most SAP shops actually use

Being honest about this: if your organisation already runs SAP Integration Suite for other third-party connections — payment gateways, logistics providers, e-invoicing — routing GST verification through CPI alongside those is almost always the pragmatic choice. It reuses existing credential storage, monitoring, and support processes. Direct ABAP HTTP calls make more sense for a smaller, self-contained landscape without existing middleware, a one-off batch job, or a sandbox proof of concept before a broader middleware rollout. Neither approach changes what you actually send — the request and response shape are identical regardless of which layer makes the call. See the full response schema in the API documentation, and for the broader ERP pattern beyond SAP specifically, our guide on integrating GST verification into an ERP workflow.

Storing the API key and securing the integration

Wherever the call is made from, the API key deserves the same treatment SAP already expects for any outbound credential. In CPI, that means the Secure Parameters store or a Credential Alias configured at the tenant level, referenced by name from the integration flow rather than typed into a Content Modifier step directly — the latter puts the key in plain text inside the iFlow's design-time artifact, which then travels with every export and transport. In direct ABAP, SAP's secure storage mechanisms (or, at minimum, a restricted customizing table with tight authorization objects) should hold the key rather than a constant in the report or class itself, since ABAP source is visible to anyone with developer access to the system.

It is also worth limiting which systems and users can trigger the verification call in the first place. A background job running on a schedule with a dedicated service user is easier to audit than a call triggered ad hoc from a transaction accessible to a wide user group, and it keeps the volume of calls — and therefore the API credit consumption — predictable rather than dependent on how often individual users happen to open a vendor record.

Frequently asked questions