Setu Switchboard - A Beginner’s Guide to Orchestration#

Picture three everyday moments:

1. An ecommerce app at 7 pm: A gig worker in Mysore uploads their Driving Licence on your quick commerce app to make side income post his call center job. Your stack calls one verification provider. That provider relies on a specific source that’s having a slow day. The loader keeps spinning; the delivery partner drops.

2. A lending app at 10 am: The borrower wants a loan and needs to submit their financial details. They already have an Account Aggregator (AA) handle with, say, OneMoney, but your flow has Anumati integrated. They now have to do an extra consent step they didn’t need. Poor user experience.

3. A broking app at 12 pm: The investor has finished all legs of onboarding, except for the eSign - however, OTP queues spike for your chosen e-sign provider. The UI looks fine, but the OTP arrives late. The timer expires. Another lost conversion.

None of this is rare. It’s the daily cost of depending on a single vendor per API in a country where coverage, latency and uptime vary by state, bank, and time of day.

Conversions pay the bills, but poor UX kills conversions.

Why single-vendor stacks quietly leak conversions Coverage gaps masquerade as “random” failures - If your sole provider leans on the weaker source for a given state/bank, users fail for no fault of theirs.

Latency is local and time-based - Evening spikes, bank batch windows or OTP surges can add a few seconds at a fragile step-enough to make users quit.

AA context matters - Starting with the “wrong” AA when a user already has a handle elsewhere adds an unnecessary consent step.

Manual failover = avoidable blackouts - “Flip the switch” is never one click. It’s Slack ping-pong, dashboards and approvals. Onboarding can stall for 30–120 minutes.

One vendor = one blast radius - A minor regression or rate limit now affects 100% of your traffic because there’s nowhere else to send it.

So… why not integrate multiple vendors and be done? Because that, too, gets painful - very, very fast. Why “just add more vendors” becomes a mess There’s a good chance that your entire onboarding process has 8-20 API calls across 5-8 vendors! Now, that means that you’re stuck with problems you don’t want: Many integrations, many quirks: Different auth, headers, payloads, rate limits, webhooks, and error codes. You end up writing glue code and adapters for each.

Homemade routing logic ages badly: Hard-coded “if state=X then provider=Y” rules go stale. Engineers become traffic managers instead of shipping features. No unified view of reality: Provider-wise success/latency/error dashboards don’t line up. Comparing apples to apples across vendors is manual and noisy.

Operational drag: Incident playbooks per vendor, retry/dedupe rules per API, weekend fire-fighting when something drifts. Commercial overhead: Multiple contracts, SLAs, invoicing cycles and renewals. Legal review deja vu. Testing tax: Every adapter change means regression across 8–22 API calls and 5–8 vendors in a typical onboarding. Velocity drops.

The net effect: you traded single-vendor risk for multi-vendor chaos.

Enter Setu Switchboard#

We built Setu Switchboard to give you the upside of multi-vendor without the chaos.

In plain English: it’s a real-time decision layer that routes each call to the provider most likely to succeed right now. It’s not a static rule in code; it’s living logic using live health checks, historical performance, and contextual hints (e.g., which bank, which state, whether a user already has an AA handle).

What you get: One interface, many providers: Unified API schemas and an error taxonomy so your app speaks one language; we handle the vendor quirks.

1. Smart routing & graceful failover: Live health checks, historical performance and contextual hints (bank/state/AA handle) drive per-request decisions.
2. Dashboards that actually compare: Provider-wise funnel, latency and error views on a common scale. Spot variance by state/bank easily.
3. Policy control & safe experiments: Set routing policies, define kill switches, A/B traffic between vendors without code pushes.
4. BYOC or Setu credentials: Bring your own contracts/credentials or use ours. Keep your governance and audit needs intact.
5. Lower ops overhead: Standardised retries, idempotency, dedupe and alerting-no more bespoke glue per provider.

The three switches of Setu Switchboard#

1. VerifySwitch - identity & KYC KYC flows often call 8 - 22 APIs across 5–8 vendors (PAN, Aadhaar, DL, voter ID, liveness, OCR, masking, etc etc). VerifySwitch monitors provider performance and routes each call to the best option. Result: fewer retries, faster TAT, and less ops hassle. 2. AASwitch - Account Aggregator AA ecosystems aren’t uniform. Some AAs convert better with certain banks; users may already have an AA handle (one less step). AASwitch selects the AA with the highest probability of consent + fetch success for that user and institution-useful across lending, PFM/wealth, and F&O unlock. Read more here. 3. SignSwitch - e-sign Regulations standardise e-sign flows, but UI latency and uptime still vary. SignSwitch offers a unified, consistent UI while routing behind the scenes to the healthiest e-sign service at that moment-ideal for broking, lending, and any high-volume contracting.

Result for users: fewer screens, fewer waits, more “done.”

Result for you: fewer incidents, faster shipping, higher completion.

Our internal benchmarks show DL verification 88%→94%, AA consent/fetch +~7%, e-sign +~7–10% (context-dependent; internal benchmarks).

**Is this for you? Do the 7 min fit check **

1. Do incidents force manual switches between providers? Is your flow more than ~8 API calls across multiple vendors?
2. Do completion rates or latency swing unpredictably? Are routing rules hard-coded (and painful to update)?
3. Do you find it hard to manage different vendors - integrations, error codes, SLAs, and contracts?
4. Are your dashboards not unified, making apples-to-apples comparisons difficult?
5. Do ops and engineering lose time to vendor fire-fighting instead of shipping features?

If you nodded more than twice, it’s worth a pilot. Start simple: pick one/two APIs, route a small traffic slice for 2 weeks, and measure completion, latency, and error codes. Click here to set it up or contact us for more information