I am opening this ticket following a conversation with Shaw in the community chat regarding a deprecation notice we received for our workspace.
We need assistance identifying where a legacy endpoint is being triggered so we can update our integration before it is removed.
Details from the notice:
Deprecated Endpoint: POST /v2/list-calls
Recent Activity: More than 300 uses detected
We have thoroughly reviewed our Make.com scenarios, automation workflows, and external integrations but have been unable to locate any active processes calling this endpoint.
Could your engineering team please review the backend logs associated with this notice and help identify the source of these requests?
Specifically, we would appreciate clarification on:
Whether this endpoint is being triggered internally by any Retell dashboard functionality or system process.
If the requests originate externally, whether you can provide any identifying details such as timestamps, IP addresses, request patterns, or other information that may help us trace the source.
Any guidance that helps us locate and update the integration before the deprecation deadline would be greatly appreciated.
Hello @adeel.dev007 thanks for the details. Here’s what we found:
It’s not coming from Retell. Our dashboard and internal services only call /v3/list-calls; the v2 hits are authenticating as one of your API keys, so the caller is a customer-side client.
How to identify which client. The Monday deprecation-notice email includes an “Affected usage:” label that tells you exactly which SDK class is calling the endpoint:
SDK(Python): POST /v2/list-calls → an outdated retell-python-sdk (pre-v3) somewhere — upgrade to latest.
SDK(TypeScript): POST /v2/list-calls → an outdated retell-node / retell-sdk — upgrade to latest.
POST /v2/list-calls (no SDK prefix) → a raw HTTP client (curl, axios, an HTTP module in Make.com, n8n, etc.) hard-coded to the v2 URL. Search your codebase / scenarios for the literal string v2/list-calls and switch it to v3/list-calls.
Could you share the exact “Affected usage:” line from the email? That single string will tell us whether you’re looking for an SDK upgrade or a hard-coded URL.
Bisection plan if the email label is ambiguous. Your org has 3 active API keys:
key_088…f23f (“mike testin bol”)
key_ec5…a6be (“Test”)
key_0b6…1776 (“Security key 1”) — this one also signs your webhooks, so do not disable it without rotating the webhook signing key at the same time.
We also see two active Make.com webhook destinations on your org (one org-level, one on the “Diana” agent at agent_d779e262ba6db6b85bd663exxx). If your Make.com scenarios include HTTP modules calling back into our API, those are the likely caller — each scenario stores the API key it authenticates with. Disable / rotate one key at a time and watch whether the /v2/list-calls count stops advancing.
Per-request IP / User-Agent. Our deprecation tracker stores aggregate counts only — no per-request IP or UA. If you’d like, we can pull a 24–48h sample of raw /v2/list-calls requests from our request logs (last ~7 days available) and share back the source IPs and User-Agents to help you pinpoint the caller.
I went back and thoroughly double-checked all of our active Make.com scenarios. We do use HTTP modules, but they are exclusively used for making outbound calls. There is absolutely no HTTP module in our active scenarios that is hitting the v2/list-calls endpoint.
Regarding the deprecation email you mentioned to check the “Affected usage:” line: I searched through our Retell emails, but I’m having trouble locating that specific detail or the exact line you’re referring to.
Since we can’t find the source on our end and the email label isn’t handy, could you please go ahead and pull that 24–48 hour sample of raw request logs? Having the source IPs and User-Agents would be incredibly helpful for us to finally pinpoint exactly where these customer-side client hits are coming from.
i am getting these emails aswell and have confirmed i am not using any of those endpoints. i even deleted all agents in the workspace that it said was affected and i got another email saying its stil in use.
Hey @adeel.dev007 thanks for double-checking the Make.com side. Here’s where we land on the log sample:
**Source IPs**: retrievable in principle. Our request logs do capture the client IP x-forwarded-for) per request with ~7 days retention and can be filtered to /v2/list-calls for org_nLNYIpI8bInFHxxx. That log store isn’t reachable from this support seat though — pulling the sample needs a teammate with access to our request-log backend. I’ve noted that as the next step on our side; expect a follow-up on this thread with the IP + timestamp + status breakdown once it’s run.
**User-Agents**: we do **not** log the User-Agent header on individual API requests. The only code that reads UA is the deprecation tracker, and it only uses UA (plus the x-stainless-lang header) to bucket each hit into SDK(Python), SDK(TypeScript), or a raw-HTTP label — that bucket is exactly what shows up under Affected usage: in the Monday email. There is no per-request UA we can recover from existing storage.
A couple of things that will likely pinpoint the caller faster than waiting on the IP sample:
**Grep your codebase and Make.com scenario JSON exports for the literal string v2/list-calls.** If it’s a hard-coded URL anywhere (curl / axios / fetch / a script / an exported scenario blueprint), this single search should surface it. When you migrate, note that v3/list-calls is a POST and returns { items, pagination_key, has_more } instead of a bare array — anything reading the response as an array will break silently.
**Bisection by API key.** You have 3 active keys. Rotate one at a time (create new → swap into the integration that uses it → delete old) and watch the next Monday notice — when the v2 count stops advancing for a given week, that key is the caller. Important: per the prior note on this thread, key_0b6…1776 ("Security key 1") also signs your webhooks, so if you rotate that one, update webhookKey in the same step or webhook deliveries will fail signature verification.
If you can dig up the most recent Monday deprecation email (subject starts with [ACTION REQUIRED] and includes an Affected usage: section), the line under that header tells us in one shot whether it’s an SDK call SDK(Python) / SDK(TypeScript)) or raw HTTP — that narrows where to look.
Hi @adeel.dev007 wanted to come back to you on the log pull and on what we can / can’t do here.
What we found in our request logs: for org_nLNYIpI8bInFHxxx against /v2/list-calls over the last 30 days we have only 2 hits, both on 2026-05-25 (~20:56 and ~21:26 UTC), and both returned HTTP 500. There is no traffic on that endpoint in the last 7 days. So whatever is generating the “300+” line in the deprecation email is not landing in the same per-request log we’d normally use to fingerprint a caller.
On the IP / User-Agent sample I offered: I have to walk that back — apologies. After checking with the team, our durable request log for /v2/list-calls only stores (org_id, timestamp, path, method, status_code). We do not persist the source IP, User-Agent, api_key id, or request body for individual API requests. The deprecation tracker is the only system that reads UA / x-stainless-lang, and it uses them just to bucket each hit into “SDK(Python)”, “SDK(TypeScript)”, or raw HTTP — that bucket is the “Affected usage:” label in the Monday email, and the bucket counter resets weekly. There’s nothing else we can backfill, so a 24–48h sample with IPs/UAs isn’t recoverable.
Fastest paths to find the caller from your side:
Get the “Affected usage:” label from this Monday’s email. That single string tells you whether you’re looking for an SDK upgrade (SDK(Python) → outdated retell-python-sdk; SDK(TypeScript) → outdated retell-node/retell-sdk) or a hard-coded HTTP client (/v2/list-calls with no SDK prefix → raw curl/axios/Make.com HTTP module, etc).
Grep your code + Make.com scenario JSON exports for the literal strings v2/list-calls and client.call.v2.list. Migration is mechanical: change v2 → v3, but the response shape changes from a bare array to { items, pagination_key, has_more } — code that does response.map(...) or response.length will break silently.
Bisect your API keys. You have 3 active keys (key_088…f23f “mike testin bol”, key_ec5…a6be “Test”, key_0b6…1776 “Security key 1”). Rotate one at a time and see which integration breaks next Monday — that’s the deprecated caller. Heads-up that key_0b6…1776 (“Security key 1”) was flagged as also being used as a webhook signing key — confirm that before rotating it or signature verification will fail.
Cutoff is 06/15/2026 — after that date /v2/list-calls returns 404.
If the “Affected usage:” label and a code/scenario grep both come up empty, that’s a strong signal the caller lives in a third-party platform or vendor integration you may have onboarded but don’t currently maintain — worth checking any CRMs, dialer integrations, or analytics tools that were given an API key.
