Skip to Main Content
Feature Request FR-4596
Product Area APIs
Status CLOSED

3 Voters

Request for Change: Enhance Credential Handling in APEX_WEB_SERVICE.MAKE_REST_REQUEST

fcasett Public · Aug 9 2025

Subject: Enhancement Request for APEX_WEB_SERVICE.MAKE_REST_REQUEST to support multiple credentials or multiple credential properties.

Current Behavior

The APEX_WEB_SERVICE.MAKE_REST_REQUEST API, when used with the p_credential_static_id parameter, can currently only reference a single APEX Web Credential. This credential is limited to a single name-value pair (e.g., a single API key, a single username/password pair, etc.).

This limitation becomes a significant challenge when integrating with modern REST APIs that require multiple, distinct values in the HTTP header for authentication or authorization. For example, some cloud services require a x-api-key and an x-user-token simultaneously, which cannot be managed with a single Web Credential. Developers are currently forced to manage these separate values manually.

Proposed Solutions

I propose two alternative solutions to address this limitation, either of which would greatly improve the API's flexibility and developer experience:

Solution 1: Support for Multiple Credential IDs

Enhance the p_credential_static_id parameter to accept an array or a colon-separated string of credential static IDs. When multiple IDs are provided, the API would retrieve the corresponding Web Credentials and merge them into the request's headers.

  • API Change: Update the p_credential_static_id parameter to accept a VARCHAR2 containing a list of static IDs (e.g., 'API_KEY_CRED:USER_TOKEN_CRED'). The API would then loop through these credentials and apply the headers.
  • Example Usage: l_response := apex_web_service.make_rest_request(..., p_credential_static_id => 'CLOUDFLARE_API_KEY:CLOUDFLARE_USER_TOKEN');
  • Benefits: This approach maintains the existing Web Credentials structure while allowing for powerful, declarative combinations. It would also be backward-compatible.

Solution 2: Support for Multiple Key/Secret Pairs in a Single Credential

Enhance the APEX Web Credentials configuration UI to allow a single credential to store multiple name-value pairs, similar to how key-value storage works in other tools. This would allow a developer to create a single Cloudflare Web Credential that contains both an x-api-key and an x-user-token.

  • UI/Metadata Change: Modify the Web Credentials configuration to support an array of (Credential Name, Credential Secret) pairs.
  • API Behavior: When p_credential_static_id points to this enhanced credential, APEX_WEB_SERVICE would automatically add all defined key/secret pairs to the request headers.
  • Benefits: This is a cleaner, more logical solution for APIs that require multiple pieces of authentication data to be managed as a single unit. It would reduce the number of individual credentials a developer needs to create.

Business Value

  • Improved Security: Encourages developers to store all sensitive API keys and secrets securely as Web Credentials, rather than hardcoding them or managing them with less secure methods.
  • Enhanced Developer Productivity: Simplifies API integration by removing the need for manual header management, especially for complex APIs.
  • Wider API Compatibility: Makes APEX more compatible with a broader range of third-party REST services that rely on multi-part header authentication.
  • Better Maintainability: Centralizes all authentication logic within the Web Credentials, making it easier to update secrets or change authentication methods across an entire application.

This change would be a significant quality-of-life improvement for developers working with modern, multi-credential APIs.

We reviewed this idea carefully, and while it was interesting, we concluded that due to all the internal implications we need to take into account, it is unlikely to make its way into APEX.

Comments

Comments

  • carsten.czarski APEX Team OP 6 months ago

    Can you provide a few concrete examples on how HTTP requests would look like when you would use multiple credentials?

    All in all, allowing multiple credentials for a single REST request would lead to a lot of confusing cases. For instance: 

    • What it both credentials have the same HTTP header name? Which one “counts"?
    • What if we already have a token for one credential (e.g. OAuth), but not for the other?
    • What if totally different authentication methods are combined, e.g. OAuth together with OCI Native authentication? 

    I think, using that would very error-prone, and also confusing. Typically one does a REST request and that must be authenticated. And that leads to using one credential?

    I think, we should take a step back and have a look at your actual requirement. Which kind of HTTP request (with which authentication method) are you trying to solve? Maybe there is an APEX enhancement here, but I'm sure it would look different.

  • fcasett OP 6 months ago

    Hello Carsten,
    here is the current call I am doing when I need to invoke the REST service through my Cloudflare tunnel:

            APEX_WEB_SERVICE.SET_REQUEST_HEADERS (
               p_name_01      => 'CF-Access-Client-Id',  – required by Cloudflare Service Token mechanism
               p_value_01     => get_cf_clid,
               p_name_02      => 'CF-Access-Client-Secret',   – required by Cloudflare Service Token mechanism
               p_value_02     => get_cf_cls,
               p_name_03      => 'Content-Type',
               p_value_03     => 'application/json',
               p_name_04      => 'User-Agent',
               p_value_04     => 'APEX',
               p_reset        => TRUE                        -- Clear any existing headers and set the new ones
           );

    p_value_01 and p_value_02 are the “hidden” keys that allow my request to pass the Cloudflare Service Token verification.

    As far as I know there is no way to store these two values in APEX Credential repository and retrieve them both by invoking the APEX_AI.CHAT_COMPLETION or APEX_AI.GENERATE_COMPLETION.

    That's why I had to write this stuff myself from scratch.

    If and how this should integrate with other settings is currently beyond my limited imagination, certainly you are more competent than me in this realm.

    Kind regards,
    Flavio

  • carsten.czarski APEX Team OP 6 months ago

    Flavio,

    Client IDs are typically not considered a secret - if you create an OAuth credential, the client ID is also not protected, only the client secret is.

    So, isn't it sufficient to configure only the Client Secret as a web credential (as that is the sensitive part), and configure the other headers either with APEX_WEB_SERVICE, or with (if using for an AI service) in the Generative AI Service definition under  HTTP Headers in Advanced section.

    regards

    -Carsten