Step-by-step guide to setting up call masking for your business. From choosing a provider to going live with API integration.
Trusted by businesses across India
Call masking (also called number masking, privacy calling, or anonymous calling) is a service that sits between two parties on a phone call and shows them a virtual number instead of each other's real number. Neither party sees the other's actual phone number — both see the masked number as caller ID.
The most common setup pattern is click-to-call bridging: your application calls a masking API with two phone numbers. The API dials Party A first, and when they answer, it dials Party B and bridges both legs. Both parties talk normally, but both see the masked virtual number as caller ID. When the call ends, the connection is severed.
Teams set this up for one of three reasons:
This guide walks you through choosing a provider, integrating the API, going live, and handling the operational details — webhooks, error codes, recording retention, and compliance.
From signup to first masked call in production
Evaluate India-focused providers (Edesy, Exotel, Knowlarity, MSG91, Plivo, Twilio India) on price, billing currency, GST handling, contract terms, integration ergonomics, and compliance posture.
Create an account. With a prepaid provider like Edesy, fund a wallet via Razorpay (minimum Rs 10). With contract-based providers, sign a service agreement and wait for onboarding.
In the portal, create an API key tied to your organization. Store it as an environment variable in your application — never commit keys to git.
From your application server, POST two phone numbers to the masking endpoint. Get back a call_sid. The system dials Party A first, then bridges Party B on answer.
Configure a webhook URL in the portal. The provider POSTs JSON events (call.initiated, call.answered, call.completed, recording.ready) to your endpoint. Verify HMAC signatures before processing.
Watch for insufficient_balance, invalid_numbers, and rate_limited errors. Use status polling or webhook events to track outcomes (completed, failed, no-answer). Retry where appropriate.
Track success rate (answered vs no-answer vs failed), call duration distribution, and cost per call. Review recordings periodically for quality. Iterate on retry logic and call flow.
The decision usually comes down to four factors: pricing model, geographic focus, integration ergonomics, and compliance fit.
If your call volume is India-only, an India-native provider (Edesy, Exotel, Knowlarity, MSG91) almost always wins on cost and tax simplicity. If you need international masking, global providers (Twilio, Plivo) are necessary. Many teams run hybrid: India provider for India traffic, global provider for the rest.
Look for:
If you're in healthcare (HIPAA-equivalent), banking/lending (RBI/SEBI), telecom-regulated communication (TRAI), or payment processing (PCI-DSS), the provider needs to support the control plane you need: encryption at rest and in transit, configurable retention, access logs, tamper-evident audit trails, and BAA-style data processing agreements where applicable. Verify these before signing — retrofitting compliance after going live is expensive.
With Edesy as the example provider, the integration is three API calls plus webhook handling. Full code examples for the initiate-call endpoint in cURL, Node.js, and Python live on the API reference page.
POST two 10-digit Indian mobile numbers to /v1/masking/calls with a Bearer token in the Authorization header. Body: { "party_a": "9876543210", "party_b": "9123456789" }. The response returns immediately with a call_sid and the masked number that will be shown to both parties.
You have two options:
/v1/masking/calls/{call_sid} every 2-3 seconds until status reaches a terminal state. Simpler to implement but consumes API rate-limit budget and adds latency. Use only if your stack can't accept inbound webhooks.When recording.ready fires, the webhook payload includes a recording_url. Alternatively, GET /v1/masking/calls/{call_sid}/recording to retrieve a signed URL valid for 1 hour. Store the recording reference against your call/order record for audit and dispute resolution.
Every webhook POST includes an X-Edesy-Signature header with an HMAC SHA-256 signature of the request body, signed with your webhook secret. Verify this on every event before processing — otherwise an attacker who knows your webhook URL can spoof events. Reject any request that fails verification with HTTP 401.
| Status | Code | What to do |
|---|---|---|
| 400 | invalid_numbers | Validate Indian mobile format and de-dupe Party A vs Party B before calling the API |
| 401 | unauthorized | Rotate the API key and update the env var |
| 402 | insufficient_balance | Top up the wallet; consider implementing a low-balance alert at Rs 50 |
| 404 | not_found | The call_sid doesn't exist or recording isn't ready yet — re-check after a delay |
| 429 | rate_limited | Back off with exponential delay; consider raising the limit on Enterprise |
Mistakes we've seen teams make on their first masking integration
Polling every 2 seconds for 100 concurrent calls = 50 req/sec. You'll hit the rate limit fast. Use webhook events for state transitions; reserve polling for one-off lookups.
Without HMAC verification, anyone who knows your webhook URL can spoof events and cause downstream chaos. Verify the signature on every event before processing.
Use environment variables. Rotate periodically. Store secrets in a vault (AWS Secrets Manager, HashiCorp Vault, 1Password) — never commit to git, even in private repos.
Insufficient balance silently blocks new calls. Subscribe to wallet alerts and surface them in your ops dashboard — not just the provider's portal.
Call recordings have privacy implications. Define a retention policy (30 days? 90 days? regulator-required minimum?) before going live. Set it programmatically per call where supported.
Before cutting over from a previous provider, document the rollback: how do you flip traffic back if the new provider has an outage? Practice it. Keep both accounts live for at least 30 days.
If you forget to add your GSTIN at the first Razorpay top-up, the invoice is issued without it and you lose Input Tax Credit on that top-up. Update GSTIN in the portal before the first top-up.
If you treat 'no-answer' as a failure and retry immediately, you'll harass users with rapid-fire calls. Build backoff: 5 mins, 30 mins, 4 hours, give up. Match retry policy to use case.
Before flipping production traffic to the masking flow, walk through this list:
Most teams underestimate masking ROI because they only count direct cost (per-minute charges). The real ROI is in three buckets:
A quick calculator: at Rs 1.50/min and an average 90-second call, each masked interaction costs Rs 3 (2 minutes minimum). 10,000 interactions/month = Rs 30,000 + GST. If even 1% of those interactions get "saved" (would have failed without masking) at an average lifetime value of Rs 500, that's Rs 50,000 of recovered revenue — a clean 1.7x ROI on the masking spend alone, ignoring the harder-to-quantify trust and compliance benefits.
If your team has 1-2 backend engineers comfortable with REST APIs and webhooks, building the integration takes 2-5 days. Time-to-live is fast and you own the code.
If you're a non-technical founder, an ops lead, or your engineering team is already over-allocated, a done-for-you setup makes sense. Edesy's Number Masking Setup service starts at Rs 14,999 (Starter, 3-5 days) and goes up to Rs 79,999 (Professional, 1-2 weeks) with CRM integration, custom IVR, and compliance setup. The full list of setup packages and add-ons is here.
Either way: the per-minute usage at Rs 1.50/min is the same — the setup service is a one-time cost for getting it integrated correctly.
Discover solutions, integrations, and resources
Use cases for every industry
No monthly fees. No hidden charges. Get started instantly on our self-serve portal.
Get started on our self-serve portal. No sales call required. Rs 1.50 per minute.