Postman & OpenAPI

Import the SignCare Core and WealthScape OpenAPI specs into Postman, Insomnia, or any OpenAPI-aware tool.

OpenAPI spec URLs

Both SignCare APIs publish live OpenAPI 3.0 specifications. Point Postman (or any codegen / API client) at these URLs — the spec regenerates on each request, so your client stays in sync with the deployed API automatically.

API	Stage (UAT)	Live (Production)
Core API	`https://uat-ext.signcare.io/swagger/v1/swagger.json`	`https://ext.signcare.io/swagger/v1/swagger.json`
WealthScape	`https://uat-ext.signcare.io/swagger/wealthscape/swagger.json`	`https://ext.signcare.io/swagger/wealthscape/swagger.json`

The stage and live specs describe the same endpoints — only the servers[] base URL differs. Pick the environment that matches your integration stage.

Import into Postman

Open Postman's Import dialog

In the Postman app, click Import in the top-left, or press Ctrl+O / Cmd+O.

Paste the spec URL

Select the Link tab and paste one of the spec URLs above. For example, to import the Core API against Stage:

https://uat-ext.signcare.io/swagger/v1/swagger.json

Click Continue, then Import.

Choose the import style

Postman will ask whether to import as a Postman Collection or an API.

Pick Postman Collection if you mainly want to hit endpoints and try them out.
Pick API if you also want Postman to track spec changes and generate mocks / tests.

Most developers start with Collection — you can always re-import later.

Repeat for the second API

Run the importer again with the second URL (WealthScape if you imported Core first, or vice versa). You will end up with two collections side-by-side in your workspace.

Set up authentication once

SignCare uses two request headers: X-API-KEY and X-API-APP-ID. Configure these once at the collection level so every request inherits them.

Create a Postman Environment

Click the Environments tab → + → name it SignCare Stage (or SignCare Live). Add two variables:

Variable	Initial Value
`SIGNCARE_KEY`	your `X-API-KEY` value
`SIGNCARE_APPID`	your `X-API-APP-ID` value

Save and select this environment from the dropdown in the top-right of Postman.

Add headers to the collection

Open the imported collection → Variables / Authorization / Pre-request Script → Headers tab on the collection root. Add:

Key	Value
`X-API-KEY`	`{{SIGNCARE_KEY}}`
`X-API-APP-ID`	`{{SIGNCARE_APPID}}`

Every request inside the collection now picks these up automatically. To switch between Stage and Live, just swap the selected environment — the requests themselves don't change.

Never commit your real API key to a shared Postman workspace or to git. Keep keys in personal environments in Postman, and rotate them via the SignCare console if they leak.

Insomnia

Insomnia uses the same OpenAPI URL — Create → Import From → URL → paste the spec URL → Fetch and Import. Add X-API-KEY and X-API-APP-ID as headers on the generated request group.

VS Code REST Client / .http files

If your team prefers checked-in request files, both APIs work with the .http format used by the REST Client extension and Visual Studio's built-in .http runner:

@baseUrl = https://uat-ext.signcare.io
@apiKey = YOUR_API_KEY
@appId = YOUR_APP_ID
 
### Verify PAN
POST {{baseUrl}}/api/v1/pan/verify
X-API-KEY: {{apiKey}}
X-API-APP-ID: {{appId}}
Content-Type: application/json
 
{
  "pan": "ABCDE1234F",
  "consent": "Y",
  "consent_text": "I hereby give my consent to verify my PAN."
}

Code generation

The OpenAPI spec is compatible with standard code generators:

openapi-generator — openapi-generator-cli generate -i https://uat-ext.signcare.io/swagger/v1/swagger.json -g typescript-fetch -o ./signcare-client
swagger-codegen
orval — React Query / SWR hook generators
NSwag — .NET / C# clients

The spec uses plain-text tag names (no emojis) precisely so codegen tools produce clean class and folder names. Decorative emojis you see in this documentation site are added purely for display.

Keeping in sync with API changes

Because you import from a live URL, re-running Postman's "Sync with URL" (or re-importing in Insomnia) picks up any new endpoints the moment we deploy them. We recommend pulling the spec again before major integration milestones — you'll spot deprecated fields and new optional parameters early.

For the human-readable changelog of what changed, see Versioning.

Need help?

Try a request first — the Quickstart walks through a working PAN verify in under five minutes.
Reading a response that doesn't match the spec? Check Error Codes and Rate Limits.
Still stuck? See Support for escalation paths.

On this page