Guides
  1. GSP Credentials

GSP credentials overview

NIC's IRP and EWB portals don't authenticate you against your GSTIN directly — they authenticate via per-GSTIN portal user credentials that you provision on einvoice1.gst.gov.in and ewaybillgst.gov.in. The OneFinOps API needs these credentials to act on your behalf.

This guide is for API-only segment-1 customers. If you're using OneFinOps' web app, the same flow exists in the dashboard at Settings → GSP Credentials — you don't need to call this API.

What you upload

For each GSTIN you want to file under:

  • IRN portal credential — username + password issued from einvoice1.gst.gov.in for that GSTIN.
  • EWB portal credential — username + password issued from ewaybillgst.gov.in for that GSTIN (or for your TRANSIN, if you're a transporter without a GSTIN).

You upload them once; we re-use them on every IRN / EWB call you make for that GSTIN.

What happens on our side

  • The plaintext password leaves your client over TLS, hits our credentials proxy, and is forwarded straight to the gsp-india internal service.
  • gsp-india encrypts at rest with AES-256 keys held in our key-management vault. Plaintext is never written to disk and is never logged.
  • We expose a HasPassword: true flag on the metadata endpoint and never return the plaintext through the API. Our public API does not have a "reveal password" endpoint — the only legitimate consumer of plaintext is our IRP/EWB worker, internally.
  • A soft delete zeroises the password and tombstones the credential. The audit trail (when the credential was added, last verified, last used) is retained.

What we don't store on the OneFinOps API service

The credentials are stored in the gsp-india capability service — not in gstn-india. This separation means the customer-facing service never holds plaintext or ciphertext credentials directly; it holds only request / response artefacts. If you read our README, this is the line "Vendor-side concerns belong in the capability layer."

Verifying before persisting

Use test-connection to verify candidate credentials with the upstream vendor without committing them. Useful when onboarding a new GSTIN or rotating a password — fail fast before you burn through your worker queue.

Rotation

Just call upsert again with the new password. The previous record is replaced (same id); we don't keep historical passwords. We recommend pairing rotation with a test-connection call first so you don't lock yourself out.

Continue

Updated about 5 hours ago