How to structure the URL for DialPad API requests in Zapier

Hi ​@StoopKid 

DialPad API docs: https://developers.dialpad.com/docs/welcome

Hi ​@StoopKid 👋 Did the DialPad API docs that Troy shared a link to help you to get the URL sorted? 

If not, can you share a bit more about what you're trying to do with the DialPad API? For example:

• What action are you trying to perform (e.g. get call details, get a transcript)?
• A screenshot of your Zap setup would also help (use a tool like Zappy to remove any personal/sensitive info before sharing here)

That way we can check whether the selected Call ID field is the right one to use and help you structure the URL correctly.

Hi ​@StoopKid just checking in — did you manage to resolve this?

I’d separate the two questions first: (1) which Dialpad endpoint are you calling, and (2) which identifier that endpoint expects.

In the step before the API request, open the real run data and confirm the field is Dialpad’s immutable call ID—not a display name, phone number, Zap run ID, or recording ID. Then build the request from the endpoint template in Dialpad’s docs and map only that ID into the path or query parameter. Start with a read-only GET for call details; once that returns the expected call, reuse the same ID for transcript/recording endpoints. Also log the resolved URL, HTTP status, and response body in Zap History, but never the auth token.

We hit this exact class of issue while building Atlantic’s call-to-CRM workflow: the durable fix was to store provider_call_id, provider, and Zap run ID as separate fields, then validate the provider_call_id before any downstream write. That prevents a successful test using sample data from hiding a bad live mapping.

I’m Ege, co-founder of Atlantic, so that’s our implementation experience rather than an official Dialpad/Zapier answer. If you share the endpoint name (not credentials or account data), the expected URL shape can be narrowed down safely.