e-Invoice API Introduction

Request For Free Sandbox Access

e-Invoice API Introduction

Background

The GST Council has approved the implementation of ‘e-Invoicing’ or ‘electronic invoicing’ in a phased manner for voluntarily reporting Business to Business (B2B) invoices to GST System starting from 1st January 2020. Being the first Invoice Registration Portal (IRP), National Informatics Centre has made the e-Invoice registration services available through API mode and other modes. The taxpayers and GSPs can integrate their business systems and processes with the e-Invoice system through these APIs for seamless registration of the invoices generated/prepared on their systems.

Purpose of this portal

This portal enables/provides:

  • Developers or System integrators of the taxpayers to understand the interfacing processes of e-Invoicing systems with their business systems.
  • Registration of the users to access the APIs
    • Credentials: The portal explains how to get the credentials to access the APIs on sandbox and production environments. The credentials include client-id, client-secret, username and password.
    • OTP: The registration process involves validating the mobile number and the email address of the primary authorized signatory of the company (as registered with GST common portal) through OTP.
  • API Documentation
    • This portal provides all the information required by the application developers to integrate their systems with the e-Invoice system through APIs.
    • This includes the calling methods / URLs, JSON Schema of the request payloads, sample request payloads and sample responses, validations being applied etc., for each of the APIs.
    • Sample code extracts for reference are provided for understanding the logic and concepts.
    • Other references like the master data used in the system etc., are provided.
  • Understanding / Testing the API methods through the sandbox portal. Through this portal, the developers can simulate the use of APIs end-to-end.
    • Can understand how can the request payloads can be generated.
    • Can see how the encryption and decryption of the requests and responses work.
    • Can substitute the encrypted payload generated using their system and check for the correctness of encryption
  • By changing the parameter values in the request payloads, developers can test the successful (valid) and unsuccessful (invalid) responses for a different combination of values.
      • What will be the response if any of the credentials supplied are wrong?
      • What will be the error response when any mandatory parameters are missing in the payload?
      • What types of errors are displayed when the API fails?
    • What happens if the API is called without a valid token?