Since our client's API uses Bearer token authentication, I'm using Protected Custom Settings to securely store the access token. The Named Credential is set up with No Authentication
, and the Bearer token is added as a custom header in Apex, pulled securely from the Custom Setting field at runtime.
This approach works well for packaging: when customers install the package, they enter their Client ID and Client Secret
, and from that, the token is generated and stored automatically — so the customer doesn't need to manually handle any OAuth flow themselves.
Has anyone run into limitations with this pattern at scale, or found a cleaner way to handle token refresh within a managed package context because I'm going to listing on agentexchange.
You can drop the Protected Custom Setting and the manual refresh entirely - use an External Credential (the new Named Credential model) instead of the old No-Auth pattern, and the platform mints and auto-refreshes the token for you.
1. External Credential - Authentication Protocol OAuth 2.0, Flow Type 'Client Credentials with Client Secret Flow'. This is the exact server-to-server case: the subscriber supplies Client ID + Secret and Salesforce generates and refreshes the access token natively - no token in a custom setting, no refresh code.
2. Named Credential - points to the API endpoint and references that External Credential. In Apex just call callout:YourNamedCredential/path and the Bearer header is injected.
3. Grant access with a Permission Set (External Credential Principal Access).
All three are packageable; after install the subscriber only populates the Principal's Client ID + Secret, so auth stays isolated from your package logic - exactly what an AgentExchange security review wants.
if this helps, please mark it as the Best Answer so it helps the next person - thanks 🙂
