Client fails to fetch prompts with names containing slash

[dali-fathallah]

When we create a prompt with the name containing a slash on the UI, example feature1/resolve_problem_2.
The prompt is correctly created in the UI, but the python client fails to fetch it:

client.templates.get(prompt_name="feature1/resolve_problem_2")

Looking at the traces of the error we identify the problem in the
promptlayer/utils.py:918 (see screenshot)

When the url value is being concatenated the prompt_name value is used directly without url encoding leading to creating a new level in the url and the wrong path

[aliraza556]

@dali-fathallah @abubakarsohail Please review this PR #259

[0xXAliXx0]

I've been debugging this issue, and here's what I found:

The root cause is that the Python client does not URL-encode the prompt_name before appending it to the API URL. In the current code, the URL is built like:

url = f"{base_url}/prompt-templates/{prompt_name}"

When prompt_name contains a slash, e.g., "feature1/resolve_problem_2", the API interprets it as a path instead of a single template name, leading to 404 Not Found.

A possible client-side fix is to use Python's urllib.parse.quote() to encode the template name:

from urllib.parse import quote

url = f"{base_url}/prompt-templates/{quote(prompt_name, safe='')}"

This encodes / as %2F, which is technically correct. However, with the current backend, the API still returns 404 because it does not decode %2F.

Immediate workarounds / possible fixes:

1. Rename templates to avoid slashes, e.g., feature1_resolve_problem_2.
2. Backend fix: Update the server to properly decode URL-encoded template names (%2F) in the endpoint. Once that's done, the above client-side patch will fully solve the problem.
3. Alternative client hack: Send the template name in a query parameter instead of the path -- but that requires changes to the client code.

In short: the bug is both client and server side, but the server needs to support encoded slashes for full compatibility.