Documentation issue: "Clever" API reference for authentication exposes credentials

,

Concern

A Documentation page unexpectedly fills a real organization id into code examples

https://platform.openai.com/docs/api-reference/authentication

Expected

If you are not logged in (or use private browsing), the API reference for “Authentication”->“Organization and Projects” will show how to use your organization ID:

Unexpected

If you are logged in to your platform account, the API reference for “Authentication”->“Organization and Projects” will be populated with your real organization ID:

Issue

It might be a neat trick, but:

  • Besides making you question reality itself…someone might think this is just some placeholder fake organization.

  • This may make it very easy to make screenshots of your organization_id, to put a copy into code commits, or otherwise share examples. It should be treated as a secret.

This needs either to have a note “we’ve auto-filled in your real org-id into these examples, but never hard-code like this”, or alternately, to just discontinue the practice.


Ideally, authentication examples would be static, and be demonstrating the same environment variables that SDKs expect:

This automatically infers the following arguments
from their corresponding environment variables
if they are not provided:
        - `api_key` from `OPENAI_API_KEY`
        - `organization` from `OPENAI_ORG_ID`
        - `project` from `OPENAI_PROJECT_ID`

Code languages with OpenAI libraries that automatically use environment variables would note that the auto-retrieval is the best practice.



Related utility

Python code, producing a http headers object

def _get_headers() -> dict[str, str]:
    """
    Generates OpenAI authentication headers from environment variables for RESTful HTTP requests.
    - will use optional OPENAI_ORG_ID and/or OPENAI_PROJECT_ID if you have set them.
    - (Send Organization to switch billing of legacy user key)
    - (Send Organization + Project to employ projects with legacy user key)
    - (- Improve robustness by coding with a secrets manager)
    - Azure OpenAI unsupported: typically AZURE_OPENAI_API_KEY, sent as "api-key" header instead

    Returns:
        dict: Headers containing authorization, assistants, and content type information.
    """
    import os
    if not os.getenv('OPENAI_API_KEY'):  # can add validation of "sk-", etc
        raise ValueError("Please set the OPENAI_API_KEY environment variable.")

    return {
        'Authorization': f'Bearer {os.getenv("OPENAI_API_KEY")}',
        'OpenAI-Beta': 'assistants=v2',  # required by Assistants; other endpoints ignore
        'Content-Type': 'application/json',  # httpx's json parameter also includes it
        **({'OpenAI-Organization': os.getenv('OPENAI_ORG_ID')}
           if os.getenv('OPENAI_ORG_ID') else {}),
        **({'OpenAI-Project': os.getenv('OPENAI_PROJECT_ID')}
           if os.getenv('OPENAI_PROJECT_ID') else {}),
    }

Non-SDK usage example, which also keeps your keys out of globals:

import httpx
response = httpx.post(
    openai_chat_endpoint_url,
    headers=_get_headers(),
    json=request_body,
    timeout=900.0,  # 15 minutes, enough for o1, too long for others
)