Winter '23 リリースでは、指定ログインに次の機能が追加されました。

Announcing the Next Generation of Named Credentials
カスタムヘッダー: HTTP コールアウトと共にヘッダーとして渡される任意の名前と値のペア (API キーなど) を定義します。
権限セットの割り当て: 権限セットにリンクすることにより、指定された資格情報のセットを使用してコールアウトを行うための明示的なアクセス権をユーザーに付与します
Amazon IAM の一時的なアクセスとロールの引き受け: Amazon STS を使用して、AWS でホストされているリソースへの一時的なアクセスのための IAM ロールを引き受けます
エンドポイント間での再利用: 同じ認証システム (Google ドライブや Google カレンダーなど) によって保護されているさまざまな API エンドポイント間で資格情報を再利用します。
カスタムセットアップ UI のサポート: ISV やその他の開発チームは、Apex の新しい Connect API を使用してカスタムセットアップ UI を構築し、管理者のユーザエクスペリエンスを向上させることができます。

カスタムヘッダーと API キー
カスタムヘッダーは、リモートシステムが要求に応答するための入力として必要なパラメーターを定義する手段を提供します。カスタムヘッダーを使用することは、コードの一部に関数を配置し、呼び出し元が入力を提供できるようにする引数を定義することに似ています。このリリースでは、名前付き資格情報にカスタムヘッダーを追加するオプションが提供されます。これは、外部サービスが API キーを認証の単純な形式として使用する場合に特に役立ちます。

機密性の高い値は暗号化された方法で保存され、差し込み項目構文を介して数式で使用できます。これにより、管理者は基本認証などの一般的なプロトコルと互換性のある資格情報を作成できます。

権限セットの割り当て
Salesforce はデフォルトで安全であるため、管理者は権限セットを介して資格情報へのアクセスを明示的に許可し、Salesforce ユーザーのさまざまなグループが異なる資格情報にアクセスできるようにします。それらが同じエンドポイントに使用されている場合でも同様です。たとえば、営業担当者はリモートシステムへの基本レベルのアクセス権を持っている場合があり、営業マネージャーは、必要に応じて決定を上書きできる昇格されたアクセス権を持っている場合があります。

関連する機能は、必要に応じて、特定の ISV 管理パッケージがそれらをコールアウトに使用することを明示的に許可することにより、管理者によって作成された名前付き資格情報を保護します。

Amazon IAM の役割の引き受け
アマゾンウェブサービス (AWS) との統合を構築しようとしている多くのお客様のために、AWS Signature V4 プロトコルのサポートを拡張し、Amazon STS を介した一時的なアクセスと IAM ロールの引き受けを含めました。Salesforce は、IAM で定義された役割を引き受ける STS サービスからの一時的な有効期限付きアクセスを要求できます。これにより、AWS 管理者は、セキュリティとコンプライアンスの要件を満たしながら、インフラストラクチャをより効果的に管理できます。

さらに、これにより、将来のリリースでの Amazon の新しい RolesAnywhere 機能との互換性への道が開かれ、これらの統合をクライアント/サーバー証明書ペアで保護できるようになります。

エンドポイント全体で再利用
新しく拡張されたアーキテクチャにより、管理者は、複数の API エンドポイントに対して同じ認証が使用されている場合でも、認証の詳細を 1 か所で定義できます。より高度なアプリケーションスタックとの統合では、多くの場合、1 つの認証メカニズムを共有する複数の API エンドポイントを使用する必要があります。このようにして、機密性の高い資格情報が Salesforce で複製されることはありません。

カスタムセットアップ UI のサポート
AppExchange を介してイノベーションを提供している ISV パートナーは、多くの場合、セットアッププロセスに関連するユーザーエクスペリエンスを最適化して、摩擦を減らし、サポートコストを削減しようとします。このリリースでは、OAuth プロトコルを使用して管理パッケージで配布された名前付き資格情報を、ISV パートナーによって設計およびブランド化されたカスタムセットアップ UI 内で認証できます。これは、新しい認証プロトコルがサポートされるにつれて拡張される Apex アクセスを備えた新しい Connect API によって有効になります。

Named Credentials and External Credentials

関連

Apex Wrapper SalesforceメタデータAPI（apex-mdapi）で指定ログイン情報の使用
Named credential does not automatically refresh access token
What Is Named Credentials, AuthProvider & Use In Apex Salesforce
Salesforce to Salesforce Integration with Oauth 2.0 and Named Credentials
Named Credentials – Secure API Callouts made easier

System.CalloutException: The callout couldn't access the endpoint. You might not have the required permissions, or the named credential "xxx" might not exist.

Named callout Null in http request with named credential - What would cause it?
大文字小文字の違いは有効
In summary, apex is case-insensitive, except when it's not. And named credentials fall into the case sensitive category.

管理パッケージのときは空間名を指定する
Is this part of a managed package ?

What worked was to change the endpoint to this

'callout:xxx/api/v2/customers/BTM8dgTcRk1OfDYJ/subscription_for_items?mylistofparameters'

ie. removing the site base url

One of my parameters was also malformed. I needed to divide my epoch date by 1000.

Decimal epochDate = start.getTime()/1000;

also to note is that authorization is not necessary when using named credentials.

(NAMED_CREDENTIAL_NAME) Cannot Modify Managed Component The component you are attempting to modify is part of a managed package, and cannot be modified.

Can't upgrade managed package -getting (named credential) Cannot Modify Managed Component

I think there was a change in Summer23 which changed the metadata of named credentials. Editing and saving brings it back to the way it is in my package, thus allowing me to install the package.

デプロイ時の注意

HTTP CallOut not working in Production

If you are using Named Credentials then trusted URLs are handled automatically. Did you create the named credentials in production manually or depend on them being created via change set migration?

Named Principals are considered org-specific so if you are using those, they will not have been migrated to production. Similarly when doing sandbox refreshes, they don't get copied to the sandbox, although I see that reading the Spring'25 release notes, that may be about to change

名前付き資格情報を使用している場合、信頼された URL は自動的に処理されます。本番環境で名前付き資格情報を手動で作成しましたか、それとも変更セットの移行によって作成されることを前提としていますか?

名前付きプリンシパルは組織固有のものとみなされるため、それらを使用している場合は本番環境に移行されません。同様に、サンドボックスの更新を行うと、それらはサンドボックスにコピーされませんが、Spring'25 のリリースノートを読むと、変更される可能性があることがわかります。