Nirmitee.io
ABDM Callback Debugging: Why Your Bridge URL Is Not Receiving Requests

ABDM Callback Debugging: Why Your Bridge URL Is Not Receiving Requests

March 20, 2026
10 min read
ABDM

If you are building an ABDM integration and your callback URL is not receiving requests from the gateway, you are not alone. This is the single most common problem on the ABDM Developer Forum with 8+ threads of developers stuck on the exact same issue.

The Callback Architecture

ABDM does not return data in API responses. Instead, it calls back to your registered bridge URL. Your server must be publicly accessible, handle POST requests at specific paths, and return 202 Accepted quickly.

Step 1: Register Your Bridge URL

Use the PATCH endpoint to register your public URL:

PATCH /gateway/v3/bridge/url
Authorization: Bearer <gateway_token>

{ "url": "https://your-domain.ngrok-free.app" }

A 202 response means accepted. But it takes 5-15 minutes to propagate. Testing immediately will fail.

Step 2: Set Up a Stable Tunnel

Use ngrok over Cloudflare Tunnels. Free Cloudflare tunnels change URLs on restart, requiring re-registration.

ngrok http 3000 --domain=your-subdomain.ngrok-free.app

Step 3: Handle All Three Path Formats

ABDM sends callbacks to inconsistent URL paths:

/v3/hip/patient/care-context/discover
/api/v3/hip/patient/care-context/discover
/api/callbacks/v3/hip/patient/care-context/discover

Use a catch-all route handler that matches on path segments:

// Next.js: /api/callbacks/v3/[[...path]]/route.ts
export async function POST(req, { params }) {
  const fullPath = (await params).path.join('/')
  if (fullPath.includes('patient/care-context/discover')) {
    // Handle discovery
  }
}

Step 4: V3 Discovery is Async

The most common V3 migration bug. In V1/V2, discovery was synchronous. In V3, it is asynchronous.

  1. ABDM calls your discovery endpoint
  2. Return 202 Accepted immediately
  3. Call /on-discover with the results asynchronously

Step 5: Use REQUEST-ID from Headers

ABDM sends requestId in the HTTP header (REQUEST-ID), not in the body:

const abdmRequestId = req.headers.get('REQUEST-ID') || ''
{ response: { requestId: abdmRequestId } }

Step 6: Add Logging Middleware

export async function middleware(req) {
  if (req.method === 'POST') {
    console.log(`[CALLBACK] POST ${req.nextUrl.pathname}`)
  }
  return NextResponse.next()
}

Complete Checklist

  • Bridge URL registered (202 response)
  • Waited 15 minutes for propagation
  • Tunnel URL is stable (ngrok with fixed domain)
  • Server returns 202 for all callback paths
  • Catch-all route handles /v3/, /api/v3/, /api/callbacks/v3/
  • Discovery returns 202 then calls on-discover async
  • REQUEST-ID from header used in response.requestId
  • Middleware logs all incoming POSTs
  • HTTPS certificate is valid

Still Stuck?

At Nirmitee, we have debugged dozens of ABDM callback issues.

Need expert help with healthcare data integration? Explore our Healthcare Interoperability Solutions to see how we connect systems seamlessly. We also offer specialized Healthcare Software Product Development services. Talk to our team to get started.

Frequently Asked Questions

Why is my ABDM bridge URL not receiving callback requests?

The most common causes are testing too soon after registration, an unstable tunnel URL, and unhandled callback paths. Bridge URL registration via PATCH /gateway/v3/bridge/url returns 202 but takes 5-15 minutes to propagate, so immediate tests fail. Free Cloudflare tunnels change URLs on restart, silently breaking the registration, and ABDM sends callbacks to three different path formats your server must all handle.

How do I register a bridge URL with the ABDM gateway?

Register your publicly accessible URL with a PATCH request to /gateway/v3/bridge/url, sending your gateway bearer token and a JSON body containing the URL. A 202 response means the registration was accepted, but propagation takes 5-15 minutes before callbacks start arriving. Use a stable tunnel such as ngrok with a fixed domain during development so the registered URL doesn't change between restarts.

What callback paths does ABDM send requests to?

ABDM sends callbacks to inconsistent URL path formats — for example /v3/hip/patient/care-context/discover, /api/v3/hip/patient/care-context/discover, and /api/callbacks/v3/hip/patient/care-context/discover. Because you cannot rely on a single path, the reliable fix is a catch-all route handler that matches on path segments, then dispatches based on whether the path contains identifiers like patient/care-context/discover.

Is ABDM V3 discovery synchronous or asynchronous?

ABDM V3 discovery is asynchronous, and assuming otherwise is the most common V3 migration bug. In V1/V2, discovery was synchronous, but in V3 your endpoint must return 202 Accepted immediately when ABDM calls it, then send the actual discovery results in a separate asynchronous call to the /on-discover endpoint. Also note that V3 sends the requestId in the REQUEST-ID HTTP header, not the body.

How do I debug ABDM integration issues faster?

Work through a checklist: confirm the bridge URL registration returned 202, wait 15 minutes for propagation, use a stable tunnel domain, return 202 for all callback paths, handle all three path formats with a catch-all route, implement async discovery with /on-discover, read REQUEST-ID from headers, and log every incoming POST with middleware. If you're still stuck, Nirmitee's healthcare engineering teams have debugged dozens of ABDM callback issues across HIP and HIU integrations.