feat(DI-2719): add Signal IQ product documentation - #446
Open
siddu1819 wants to merge 62 commits into
Open
Conversation
Introduce client-facing docs for Signal IQ across AA, PDF, and bring-your-own FI data flows, and register the product in endpoints. Co-authored-by: Cursor <cursoragent@cursor.com>
Checklist to merge a PR 🚀To merge this pull request, please take time to complete the checklist. What action did you perform?Review the corresponding checklist items for the action you performed and mark them done. Edit an existing content (MDX) pageChecklist
Edit an existing API reference pageChecklist
Add a new content (MDX) pageChecklist
Add a new API reference pageChecklist
|
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
…ems. Co-authored-by: Cursor <cursoragent@cursor.com>
Paths containing api-reference force the OpenAPI viewer, so Signal IQ MDX pages rendered blank. Move them to output-apis and redirect the old URLs. Co-authored-by: Cursor <cursoragent@cursor.com>
Move output fetch docs to OpenAPI playground pages so responses get the same status-code coloring as Insights, with a landing page and separate specs per format. Co-authored-by: Cursor <cursoragent@cursor.com>
Remove the output-apis self-redirect loop so the API reference index page loads. Co-authored-by: Cursor <cursoragent@cursor.com>
Use a single api-reference OpenAPI page so the left bar switches to Setu Insights JSON, Excel and XML operations instead of nested docs pages. Co-authored-by: Cursor <cursoragent@cursor.com>
Use a fresh outputs/api-reference URL to avoid stale redirects, with OpenAPI Overview plus Setu JSON, Excel and XML in the left panel. Co-authored-by: Cursor <cursoragent@cursor.com>
Single api-reference OpenAPI page so the left panel shows Overview, Setu JSON, Setu Excel and Setu XML. Clear poisoned nested redirects. Co-authored-by: Cursor <cursoragent@cursor.com>
Add api-reference/json|excel|xml page shells so the cached redirect target can render the OpenAPI playground with Overview and Setu JSON/Excel/XML. Co-authored-by: Cursor <cursoragent@cursor.com>
Avoid year-long cached redirects on /api-reference by using /siq-api/api-reference so Overview, Setu JSON, Excel and XML can render like Insights. Co-authored-by: Cursor <cursoragent@cursor.com>
…ldren. Move overview content back to output-apis.mdx, serve JSON/Excel/XML as separate OpenAPI pages, and remove redirect loops from legacy siq-api paths. Co-authored-by: Cursor <cursoragent@cursor.com>
The output-apis split hit CDN redirect loops on staging. Restore the siq-api/api-reference setup that served Overview plus Setu JSON, Excel and XML correctly. Co-authored-by: Cursor <cursoragent@cursor.com>
Restore d56952b siq-api OpenAPI layout and replace markdown tables in the Overview with lists so they render correctly in the API reference UI. Co-authored-by: Cursor <cursoragent@cursor.com>
Use /report-apis/api-reference so CDN cannot serve stale redirect loops from siq-api/output-apis. Keep Insights-style OpenAPI left nav with Overview, Setu JSON, Setu Excel and Setu XML. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Use real Setu JSON and Excel success payloads, remove Setu XML from the API reference Overview and left nav. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
…rence Client-facing developer documentation for the UPI Issuance onboarding surface, published to the Setu docs site. - Guide pages: overview, quickstart, API envelope, device binding, OTP verification, VPA management, programs, payee blocklist, QA-env testing. - OpenAPI spec (api-references/payments/upi-issuance.json) driving the interactive API reference: human-readable operation summaries, doc-ordered sections, internal endpoints excluded, per-operation error-code enums + examples, and consistent deviceId / mobile / idempotencyKey / cursor / token / id conventions across docs and refs. - Nav registration in endpoints.json, menuItems.json, redirects.json. Spec/code counterparts land under UPIIS-33/34/35. Closes UPIIS-47
- swap 7 local img srcs to docs-assets CDN - add field constraints/regex to user-otp & device-binding tables Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move the new resolution endpoint off /onboarding/ to /api/v1/vpa/resolve (VPA/payments operation, not onboarding) across the OpenAPI reference, the guide, and the QA-testing X-Sim-Resolution examples. Existing /onboarding/ endpoints are unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
44e7782 added vpa-resolution.mdx and renumbered the surrounding pages' frontmatter, but never regenerated menuItems.json. The app derives both routes and sidebar from that file, so the page 404'd. Syncs menuItems.json to the MDX frontmatter: VPA resolution at 5 (after Payee blocklist), Testing on QA env 5 -> 6, API reference 6 -> 7. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"money" -> "payment", and drop the envelope / /api/v1 / active-user / idempotencyKey preamble: the route line below already states all of it, and idempotencyKey is carried by the OpenAPI spec and api-envelope. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
resolveVPA was tagged "VPA management", so it rendered as one item inside that section rather than mirroring the guides, where VPA resolution is a page of its own. Adds a "VPA resolution" tag and retags the operation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two descriptions on the VPA resolve operation named the NPCI protocol call (ReqValAdd) directly. Replaced with a plain statement that resolution happens via NPCI. Error codes and NPCI itself stay. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- status: spell out what RESOLVED / PENDING / FAILED each mean rather than the terse "(details present)" / "(error present)" shorthand - entityType: PERSON is a non-merchant VPA, ENTITY a merchant VPA - "Present on RESOLVED" -> "Present in the API response in case of successful resolution" - "Present when verified" -> "Present when the payee VPA is a whitelisted / verified VPA" - "Present for a resolved merchant" -> "...merchant VPA" - verifiedUrl is a brand url, not a callback url Applied to both the OpenAPI spec and the guide page so they match. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The merchant sample omitted franchiseName and verifiedLogo, and the person sample omitted verified — all three are documented in the field tables directly above. The spec's 200 example was also self-contradictory: entityType PERSON carrying verifiedName "Brand-X" and a brand logo. Replaced with a complete, consistent verified-merchant response covering every field the schema defines apart from the failure-only pair. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Checked against the implementation in setu-upi-issuance: - name is NOT guaranteed masked. On our own handle it is the decrypted account name on record (resolve.go returns derefOr(v.AccountName); the integration test asserts "Test Holder"). On a foreign handle it is whatever the payee PSP put in the RespValAdd maskName attribute, which by convention carries the real name — our own outbound holderName() returns it in the clear, masking it only in logs. - verified is omitted when false: the handler only sets it via `if res.Verified`. So it is present only for a verified payee, not on every successful resolution. Reverts the "verified": false line added to the person sample in 4a79b3b. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The implementation emits lowercase status values. vparesolve.State defines pending / resolved / failed, and the comment there calls the spelling the wire contract: "The values are LOWERCASE, matching every other status the switch puts on the wire (app_user and vpa both carry active / deregistered), so a client never has to remember which surface shouts and which does not." The integration test asserts res["status"] == "resolved". Docs said RESOLVED / PENDING / FAILED throughout. Lowercased in the status enum, its description and example, the response examples, the errorCode / errorMessage notes, the guide's status table and samples, and the qa-testing reference to the polling status. Only these three status values changed. The uppercase enums (PERSON, ENTITY, SAVINGS, CURRENT, SMALL, LARGE, ONLINE, OFFLINE, and the ownership values) are uppercase in the implementation and are untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The directive now spells the outcome field `status`, carrying the same
resolved / failed vocabulary as the resolve response (simresolve.go:
"An earlier revision spelled this field `outcome` with success /
failure, which meant a client pinning a failure wrote one word and read
back another"). The legacy `outcome` spelling is still accepted but is
never emitted, so document the current name.
- qa-testing: `outcome` (success|failure) -> `status` (resolved|failed),
and the forced-failure example now sends {"status":"failed",...}
- spec X-Sim-Resolution: same, plus `verified` is an object
({name,url,logo}) whose presence flags the payee as verified — the
description and both examples had it as a boolean
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- errorCode: "Network error code" -> "VPA resolution failure error code" - add a line break above the merchant-block paragraph Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
50e3fa5 dropped it along with the rest of the intro preamble, which left this the only feature page not mentioning it — payee-blocklist, vpa-management, device-binding and user-otp all do. Restored in the per-operation position those pages use (after the request field table) rather than back in the intro. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Fill in the actual X-Sim-Resolution defaults from the upstream mock (buildRespValAddInner) instead of saying "a default": they differ by entityType — MOCK****PAYEE/SAVINGS for a PERSON, BRAND****X/CURRENT plus the Brand-X merchant block for an ENTITY, ICIC0000052 either way. - Document the no-header behaviour: the outcome is driven by the payee VPA (fail/invalid -> failed, merchant/brand -> ENTITY, else PERSON), not by a fixed default response. - Convert the two plain fenced blocks to CodeBlockWithCopy — this was the only UPI Issuance page not using the component. - Add the two vpa/resolve steps to the full QA env run table. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds the webhook section to the VPA resolution guide: the key material the TPAP supplies, the X-Setu-Event event, the sealed envelope, the receiver's validation order, and Setu's retry behaviour. Verified against setu-upi-issuance: - event name / header notify/ports: EventVPAResolve, EventHeader - body is the resolve response field for field, terminal status only - envelope ct/sk/iv/api/clientId/sig, api = the event name; RSA-OAEP (SHA-1) wrap of a 32-byte key, AES-256-CBC, sig = HMAC-SHA256 over the plaintext envelope/outbound.go: Seal - 3 attempts, 500ms doubling backoff, 5s per attempt, retry on 5xx/408/ 429 only configs/config.json + notify.retryableStatus Also fixes two examples that showed entityType PERSON alongside verified:true with Brand-X branding — a person carrying merchant brand verification. The webhook sample is now a plain PERSON matching the poll's person sample, and the spec's schema-level example is synced to the path-level one so the two no longer disagree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Drop second-person voice from the notification section and the QA resolution notes. Every other UPI Issuance page is written in third person around "the TPAP / Issuing App"; these two were the only ones using you/your (41 and 4 occurrences). - Markdown is not processed inside <Callout>, so **mirror image** and **decrypted plaintext** rendered literally. Switched to <b>/<i>, the pattern the other callouts already use. Same bug fixed in api-envelope, where `clientSecret` in a callout was showing its backticks. - "so there is nothing to announce" -> "so a notification is not needed" - Sample target url now tpap.example.com, matching the API spec's own example, instead of your-app.example.com Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Line breaks before the mirror-image callout, the per-environment note, the idempotency note and the all-attempts-failed note. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ssuing App "receiver" was the last actor name in the notification section that did not match the house term used everywhere else in these docs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs(UPI Issuance): VPA resolution + resolution notification, and restore the UPI Issuance doc set
Document exponential backoff plus EOD webhook retries, and wire the new reference into nav. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Keep BSP codes from wrapping mid-token in the PDF Flow table. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Add an API reference landing page for PDF APIs and Reports, and disable Try-it on PDF APIs. Co-authored-by: Cursor <cursoragent@cursor.com>
Move Reports OpenAPI under report-apis/reports so it no longer collides with the parent path. Co-authored-by: Cursor <cursoragent@cursor.com>
The sidebar still navigates to that legacy path; stop it from bouncing into Reports. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Add PDF upload BSP-103/104/106/107 examples and drop Try-it servers from API specs. Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Introduce client-facing docs for Signal IQ across AA, PDF, and bring-your-own FI data flows, and register the product in endpoints.