Going Live

UAT (https://uat-ext.signcare.io) returns deterministic dummy data for most flows — there is no upstream onboarding required. Production (https://ext.signcare.io) routes traffic to real upstream systems, and several of those systems require additional onboarding before live calls work. This page lists what's required per API.

Quick reference#

If your API isn't listed and isn't in the synchronous group above, it's probably plug-and-play — UAT keys work in production with no extra setup. Confirm with your account manager before assuming.

---

CKYC Verification#

CKYC (CERSAI) requires a fixed source IP for all live API traffic. The IP is whitelisted upstream, and every realtime request must originate from it.

How it works#

For realtime API connectivity, we share a setup script that installs and configures a Squid forward proxy on a server you designate for this integration.

The proxy ensures all realtime API traffic originates from the server / IP address that has been approved and whitelisted for the integration. Instead of our application calling the upstream realtime API endpoint directly, all realtime requests are routed through this proxy, ensuring consistent source IP routing and secure connectivity.

What the setup script does#

The script performs the following configuration steps on the server:

1. Installs Squid along with the required authentication utility.
2. Creates a dedicated proxy username and password for authenticated access.
3. Takes a backup of any existing Squid configuration before making changes.
4. Writes a controlled Squid configuration specifically for authenticated forward proxying.
5. Opens the proxy listener on port 3128.
6. Disables caching, since realtime API traffic should never be stored by the proxy.
7. Restricts outbound requests to only safe and required destination ports.
8. Blocks access to private networks, localhost, link-local ranges, and cloud metadata endpoints.
9. Removes forwarding/privacy headers such as X-Forwarded-For and Via to avoid leaking unnecessary network information upstream.
10. Validates the Squid configuration before applying it, ensuring configuration correctness.
11. Starts the Squid service and enables it for automatic startup.
12. Prints the final proxy URL along with a test command so connectivity can be verified immediately after setup.

Why these steps are necessary#

• Authentication — only approved systems / applications can use the proxy.
• Port and destination restrictions — prevent the proxy from being misused as a general-purpose network tunnel. It is intended only for outbound realtime API traffic, not for internal network access.
• Metadata endpoint blocking — protects cloud credentials and instance metadata from being accessed through the proxy.
• Caching disabled — ensures API request/response data is not stored on the proxy, which is critical for realtime and sensitive integrations.
• Header removal — keeps proxy behavior predictable and prevents unnecessary network details from being exposed to upstream systems.
• Configuration validation — minimizes deployment risk by verifying the configuration before applying it; an invalid configuration won't silently disrupt connectivity.

Network access required#

For the setup to work correctly, the following firewall / network rules need to be in place:

• The server should allow inbound traffic on port 3128 only from approved source IPs.
• The server should allow outbound access to the required realtime API endpoints.

Post-setup verification#

Once the setup is complete, we run a test request through the proxy to confirm that traffic is successfully routing through the approved server / IP and that realtime API connectivity is functioning as expected.

What to do#

1. Designate a server for the integration (a small dedicated VM is fine).
2. Apply the inbound / outbound firewall rules above.
3. Notify your SignCare contact — we share the setup script and run it together.
4. After the post-setup verification test passes, your CKYC traffic in production goes live.

Reference documents#

The CKYC programme onboarding follows three stages. We share each document at the matching stage — they're available here for preview, but the contractual versions come from your SignCare contact.

PDFs open in a new tab. They are unauthenticated downloads — don't link to them in customer-facing material, send them via your usual onboarding channel.

UAT (uat-ext.signcare.io) does not require any of this — UAT returns fixed dummy data for CKYC search and download. Live production traffic only.

---

NeSL eStamp#

NeSL (National E-Governance Services Limited) onboarding is the longest of the lot — typically around a month end-to-end — because it involves upstream provisioning and credential issuance.

Details required for NeSL onboarding#

Have these ready to speed up the process:

• Name of the entity
• CIN
• Registration / License No. (RBI / IRDA / SEBI, as applicable)
• Date of Incorporation (DOI)
• PAN / Employee Code & Designation of the authorised signatory
• NeSL agreements — signed in the format your account manager provides

Prerequisites for activation#

• A funded NeSL eStamp wallet (prepaid — stamp duty + charges are debited per issuance). Kerala, Madhya Pradesh, Maharashtra, Telangana and West Bengal (marked ✓* in the state table) use a separate NeSL wallet — fund it independently.
• Second Party PAN must match the PAN registered on your NeSL eStamp account.

---

SHCIL (Stock Holding) eStamp#

SHCIL issues eStamps via its Digidoc platform. Onboarding is comparatively fast — typically about one week end-to-end — but it does require a signed Letter of Authority, certificate/IP exchange, and a funded wallet before live issuance works.

Onboarding process#

1. Submit onboarding details (below) to your SignCare account manager.
2. Letter of Authority — provide a Letter of Authority on your company letterhead authorising SignCare to provide digital stamps on your behalf. Your account manager shares the format.
3. Certificate & key exchange — SignCare exchanges RSA certificates with Digidoc (requests are hybrid-encrypted: AES payload + RSA key exchange) and provisions the API key. Handled by SignCare; no action needed from you.
4. IP whitelisting — SignCare's outbound IP is whitelisted on the Digidoc portal, and Digidoc's callback IP range is whitelisted on our side for execution callbacks. Handled by SignCare.
5. Wallet provisioning — your SHCIL eStamp wallet is created and you fund it (prepaid). Stamp duty + SHCIL slab service charge + the per-eStamp API charge are debited per successful issuance.
6. UAT verification — issue a test eStamp end-to-end in UAT (uat-ext.signcare.io returns deterministic dummy data), then a single live smoke test in production.

Details required for SHCIL onboarding#

• Name of the entity
• CIN
• Registration / License No. (RBI / IRDA / SEBI, as applicable)
• Letter of Authority on company letterhead authorising SignCare to provide digital stamps (format provided by your account manager)

Prerequisites for activation#

• Signed Letter of Authority approved by SHCIL.
• SignCare outbound IP whitelisted on the Digidoc portal; Digidoc callback IPs whitelisted on our side.
• A funded SHCIL eStamp wallet for your company.
• Your API key has the StockHoldingEStamp.Create permission.
• SHCIL's merchant pool (shared, managed by SignCare ops) is funded — monitored on our side.

Charges & state coverage#

SHCIL charges are slab-based on the stamp-duty amount and vary by state. See eStamp Information for the full government-charge slab table, the state availability matrix, and a NeSL-vs-SHCIL comparison to help you choose a provider.

Reference & support#

Onboarding documents (Letter of Authority format, agreement templates) are shared by your account manager through the usual onboarding channel — they are not public downloads. For help, raise a ticket via SignCare Support.

---

Physical eStamp#

Physical eStamp requires wallet provisioning and branch mapping before live procurement orders can be placed. The wallet is funded upfront and debited per order.

---

eSign#

The Go-Live process for eSign depends on which signing flow you use (Aadhaar eSign, DSC, or NeSL-backed eSign). Each flow has its own onboarding.

---

DigiLocker#

DigiLocker access is gated by partner registration with the DigiLocker programme and per-document-type approvals.

---

Aadhaar OVSE#

Aadhaar OVSE (Offline Verification) goes through UIDAI directly. SignCare is the registered offline-verification entity; your company is provisioned under that registration so you don't have to onboard with UIDAI yourself.

---

WealthSync#

WealthSync (Account Aggregator framework) involves regulatory registration with the AA ecosystem and per-FIP (Financial Information Provider) onboarding.

---

Asking for help#

Stuck on a Go-Live step, or unsure whether your API needs onboarding at all? Reach out via SignCare Support and we'll route the request to the right onboarding contact.

See also#

• eStamp Information — state availability, government charges, provider comparison
• Environments — Stage vs Live URLs
• Authentication — API keys, headers
• Webhooks — for asynchronous flow callbacks