Partner-gated / closed

Payments / UPI (India)·agent-generated · deepseek-v4.1-flash·checked 2026-10-28

Navi (UPI, India)

difficulty

5/5

No OAuth surface at all: all six OIDC/OAuth discovery probes on developer., auth. and api.navi.com failed, so there is nothing self-serve to build against; delegated UPI access realistically requires a PSP-bank + NPCI partner track — months, discretionary (inferred, no Navi source found).

First working connection

~1 hour (to confirm there is nothing to build against)

Production / approved

8-24+ weeks if a partner track exists (inferred); otherwise never

Composio managed OAuth

Bring your own app

Not in Composio's managed-OAuth list — you'll need your own OAuth app (or it isn't a Composio toolkit yet).

who does itagent 6you 2provider 0

evidencetested 7sourced 3inferred 26

◆ agent run7 pages read2/3 quotes verified verbatim71s$0.019deepseek-v4.1-flash

01Pick your path

Public OAuth / OIDC discovery

when You want delegated user access today with self-serve credentials

→ Dead end. Six well-known fetches across developer.navi.com, auth.navi.com and api.navi.com returned no metadata (fetch failed / timeout). Nothing to integrate against.

Partner route: PSP bank + NPCI (TPAP) or merchant/collect API

when You have a registered company, an India entity or partner, and a genuine payments use case

→ The only realistic route to act on behalf of Navi UPI users. Discretionary business vetting, months of elapsed time, security review likely. Not documented in any source here — inferred.

No-API fallback: UPI deep link / collect request

when You need to ship something now and can live with user-approved, one-shot requests

→ Agent generates a payment intent or collect request; the user approves in their own UPI app. No token, no balance or history access. Ships in days, but it is not delegation.

Wrong-provider shortcut (Naver / SumUp)

when You see 'Navi'/'Naver'/'SumUp' in search results and assume they are interchangeable

→ Won't work. Naver (S1, S6) and SumUp (S4) are different companies with different currencies, entities and OAuth stacks.

02Time & effort

Hands-on work

1.9 h – 5.3 h

Waiting on others

8 weeks – 24 weeks

You're actually working

<1% of elapsed time

Phases

start↑ first working connection, then production pathproduction

DEVDiscovery probes on all three hosts5–15 minutesinferredRe-run from a browser and an India-region IP before treating the result as final.
DEVDocs hunt + name-collision check20–60 minutessourced[S1][S4][S6]Sources S1/S6 are Naver (Korean), S4 is SumUp; none describe Navi.
DEVDraft partner ask + architecture one-pager1–3 hoursinferredAgent produces the email and the security summary; you review before it leaves the building.
PRODYou send it with company, KYC and use-case details30–60 minutesinferredProvider's login, legal identity and business details are yours, not the agent's.
PRODBank partner / NPCI review (if a track exists)wait 8–24 weeksinferredOrder-of-magnitude estimate only; nothing in the sources states a Navi timeline.

agent can do it you waiting on providerbar widths ∝ √time, so short tasks stay visible

03Steps

0/8 done

Get a working connection

Reproduce the discovery checkagentinferred
Re-run the six discovery fetches yourself, from a browser and an India-region IP. All six failed in this run (three fetch failures, two timeouts); confirm before you tell anyone Navi has no OAuth.
◆ prepared by agent · Discovery re-probe loop
```
for h in developer.navi.com auth.navi.com api.navi.com; do
  for p in .well-known/openid-configuration .well-known/oauth-authorization-server; do
    printf '== https://%s/%s  ' "$h" "$p"
    curl -sS -m 10 -o /dev/null -w '%{http_code}\n' "https://$h/$p" || echo unreachable
  done
done
```

Rule out the name collisionsagentinferred[S1][S4][S6]

Search results for 'Navi OAuth' surface Naver (Korean, S1/S6) and SumUp (S4). Neither is Navi. Write the distinction down before anyone wires in the wrong endpoints.

◆ prepared by agent · Name-collision cheat sheet

Navi (navi.com) — India, UPI app + lending. Target of this guide.
Naver (naver.github.io / developers.naver.com) — Korean search/portal. Naver Login OAuth. NOT Navi. [S1][S6]
SumUp (developer.sumup.com) — European payments. OAuth 2.0 at api.sumup.com. NOT Navi. [S4]
Rule: no endpoint, scope or app-console URL from Naver or SumUp goes into a Navi build.

Confirm there is no developer portal (human check)youinferred
Check navi.com for a developer, partner or business link and a contact address. No such URL appears in the sources, so the agent cannot hand you a link — you confirm whether one exists. Until then, the honest answer to your planner is: no public developer surface found.

Draft the partnership ask (agent-written)agentinferred

State exactly what the agent would do on the user's behalf, that consent is captured per action, and that you accept a vetting process. Ask which track exists before pitching features.

◆ prepared by agent · Draft partner-ask email

Subject: Partner/API access request — delegated UPI access for an AI agent

Hi <Navi partnerships team>,

We build <product>, an AI agent that helps users manage payments. We want to act on behalf of a user's Navi UPI account with their explicit consent.

Three questions:
1) Does Navi offer a partner or developer API for third-party apps to act on behalf of a Navi UPI user (payment initiation, transaction history, profile)?
2) If yes, which track applies — TPAP via a sponsor PSP bank, or a merchant/collect API — and who owns onboarding?
3) What documents and timeline should we plan for?

We can share an architecture and security summary on request (token storage, PKCE, no credential handling, consent and deletion design). We are not asking for sandbox credentials before you have assessed fit.

Thanks,
<name, company, website>

Build the no-API fallback in parallelagentinferred
While the partner track runs, ship a version that generates a UPI payment intent or collect request and hands approval to the user in their own app. No delegated token, no history access — but it is shippable in days and honest about its limits.

Make it production-ready

You send it and supply company/KYC detailsyouinferred
Legal identity, company domain, KYC documents, named business contact. The agent cannot sign or verify identity; the provider will only engage with a person.
Prepare the security one-pager for reviewagentinferred[S3][S7]
One page for the bank partner: what data moves, where tokens live, how consent is captured and revoked, retention and deletion, subprocessors. Generic payments-review expectations (HTTPS, PKCE, no token logging) are echoed in app-review docs like S3/S7.
Schedule a quarterly re-probeagentinferred
Set a recurring agent job to re-fetch the six discovery URLs and diff the result, so a newly published auth.navi.com/developer.navi.com is caught the week it appears.

04Requirements, scopes & nuances

You'll need

▸First, a documented OAuth/API program — none observed. All six discovery probes failed and no Navi developer documentation exists in the sources. inferred
▸A registered legal entity with Indian payment-market presence (or an Indian partner/PSP bank sponsor) — standard for UPI participants, not stated in any source here. inferred
▸A named business owner at Navi/the sponsor bank, reached by email from a company domain. No contact address is published in the sources; you must find it. inferred
▸Privacy policy, HTTPS everywhere, secure token storage, PKCE for public clients, no token logging — generic review expectations echoed by app-directory docs like S3/S7, and near-certain for a payments partner. inferred[S3]
▸A security/architecture write-up the bank partner can review: data flows, token handling, consent capture, deletion policy, subprocessor list. inferred

Gotchas

!The one probe that returned a real OAuth response (302 invalid_client) was https://api.sumup.com/authorize — SumUp's endpoint (S4), not Navi's. It proves the probe harness works; it proves nothing about Navi. sourced ❝[S4][S1][S6]
!Absence of /.well-known/openid-configuration is not proof of absence of an API, but for a payments provider it is a reasonable signal that there is no public OAuth/OIDC program. Re-probe before quoting this verdict to anyone. inferred
!api.navi.com timed out while developer./auth. failed to fetch — could be WAF/geo blocking non-browser clients rather than a missing service; use a browser and an India-region egress before concluding anything. inferred
!Delegated UPI access carries device binding and per-transaction UPI PIN entry; an AI agent can prepare the payment request but the human always approves. Do not promise unattended payments in your product copy. inferred
!Where a provider does publish OAuth (like SumUp), the sensitive scopes (payments, payment_instruments) are manually verified even though the app registration itself is self-serve — expect at least that much gating anywhere in payments. sourced ❝[S4]

Scope / permission	Tier	Note	Evidence
(none published)	gated	There is no scope catalogue to choose from. Nothing to request, nothing to minimise — the narrowest scope set is the empty set until Navi publishes one.	inferred
payment initiation / transaction history (expected shape, undocumented)	restricted	If a partner track opens, assume payment initiation and account history are separately gated and manually verified, mirroring how payments providers treat money-moving scopes (cf. SumUp's payments / payment_instruments, S4).	inferred[S4]

05If you get blocked

✕No developer portal, console URL, or contact path for Navi appears in any source or probe, so there is no self-serve way to get credentials.inferred

→ Treat the email draft in step 4 as the deliverable, and only build after someone at Navi confirms a partner track in writing.

✕UPI access on behalf of a user is a regulated activity in India (TPAP / PSP-bank sponsorship / NPCI approval), not a self-serve OAuth product; a developer cannot grant themselves this.inferred

→ Ask explicitly in the first email which track applies (TPAP via a sponsor PSP bank vs. merchant/collect API) before investing any engineering time.

✕The agent cannot stand in for the user's UPI app: even with a token, UPI mandates user approval per transaction (device binding, UPI PIN), so an unattended agent can at most prepare requests.inferred

→ Budget 1-3 hours of agent time to build the fallback: a UPI deep-link payment intent or a collect request where the user approves in their own app; you own merchant onboarding for it.

✕Name confusion: 'Navi' (India, UPI) vs 'Naver' (Korea; S1, S6) vs 'SumUp' (S4) — the only successful OAuth probe in this set was against api.sumup.com, a different provider.inferred[S1][S4][S6]

→ Do not wire Naver or SumUp redirect URIs, scopes, or endpoints into a Navi integration on the assumption they are equivalent.

06Evidence: what was tested, sourced, and still uncertain

$ probes: live GETs with a dummy client_id, no credentials

✓ Discovery document (/.well-known/openid-configuration) → n/a

https://developer.navi.com/.well-known/openid-configuration

unreachable: fetch failed

∴ No OIDC metadata published on the developer subdomain (fetch failed outright). Could be a nonexistent host or a network/DNS block — 'not published', not 'definitely absent'.

✓ Discovery document (/.well-known/oauth-authorization-server) → n/a

https://developer.navi.com/.well-known/oauth-authorization-server

unreachable: fetch failed

∴ Same result for the OAuth 2.0 authorization-server metadata; no sign of an AS at developer.navi.com.

✓ Discovery document (/.well-known/openid-configuration) → n/a

https://auth.navi.com/.well-known/openid-configuration

unreachable: fetch failed

∴ No OIDC metadata on the auth subdomain — the host either doesn't resolve or refuses the request. There is no login/SSO surface you can point an agent at.

✓ Discovery document (/.well-known/oauth-authorization-server) → n/a

https://auth.navi.com/.well-known/oauth-authorization-server

unreachable: fetch failed

∴ No OAuth AS metadata on auth.navi.com either. Both standard discovery paths are dry across the hosts checked.

✓ Discovery document (/.well-known/openid-configuration) → n/a

https://api.navi.com/.well-known/openid-configuration

unreachable: The operation was aborted due to timeout

∴ Request aborted on timeout rather than failing fast — the API host appears to exist but may be firewalled, geo-blocked or slow. Retry in a browser from an India-region IP before drawing conclusions.

✓ Discovery document (/.well-known/oauth-authorization-server) → n/a

https://api.navi.com/.well-known/oauth-authorization-server

unreachable: The operation was aborted due to timeout

∴ Same timeout for the OAuth AS path. Nothing indicates a public authorization server on api.navi.com.

✓ Authorize endpoint with a fake client_id → 302

https://api.sumup.com/authorize?client_id=probe_invalid_client&response_type=code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback

redirect → https://auth.sumup.com/flows/oauth2/error?error=invalid_client&error_description=The+requested+OAuth+2.0+Client+does+not+exist.

∴ This is SumUp's endpoint, not Navi's. It proves the probe method works (302 → invalid_client) but is zero evidence about Navi; do not cite it as a Navi OAuth finding.

Sources read

[S1] 애플리케이션 등록 third-party
[S2] Pass app review third-party
[S3] App Review Process third-party
[S4] OAuth 2.0 | SumUp Developer official
[S5] App review process and requirements for the Google Workspace Marketplace official
[S6] 사전 준비 사항 - Open API 가이드 official
[S7] App Review Process third-party
[composio] Composio — Managed OAuth apps directory official
[probe] Live HTTP probes run by the agent (dummy client_id, no credentials) probe

Still uncertain

? No source in the provided set is about Navi. S1/S6 are Naver (Korea), S4 is SumUp, S2/S3/S5/S7 are app-review docs for Shopify, CashPanel, Google Workspace and Midday. Every Navi-specific statement here is therefore either a probe result or my inference.
? The probes are negative evidence only: a failed fetch can mean 'no service', 'DNS/geo/WAF block', or 'wrong hostname'. api.navi.com timed out rather than 404'd, which is ambiguous.
? I could not verify whether Navi has a private/partner API, sandbox, or developer portal behind a login. Absence from public discovery does not rule that out.
? The TPAP / PSP-bank / NPCI framing and the 8-24 week estimate come from general Indian payments knowledge, not from these sources — treat both as estimates to be checked with Navi directly.
? The verdict of 5 ('effectively closed') is a judgement call from the missing public surface plus a regulated domain; if Navi runs a merchant collect API you can onboard, the real difficulty could be 3-4.
? Review-timeline patterns in S3/S7 (3-5 business days) and S5 ('several days') belong to other platforms and must not be quoted as Navi's turnaround.
? Generated automatically; no app was registered and no review was submitted.