Why use customer-owned credentials
Customer-owned credentials preserve the direct supplier relationship and its commercial terms while removing supplier-specific integration code from the customer application.
A connection has several readiness layers
Credential presence is necessary but not sufficient.
- Supplier account and contract approved
- Correct sandbox or production credentials
- Credentials encrypted and stored
- Outbound IPs allowlisted when required
- Supplier-side access activated
- A real request verified
Encryption and trust boundaries
The encryption key should remain outside the database. Encrypted credentials must be bound to the owning organization, connection and environment so copied ciphertext cannot be reused in another context.
Troubleshooting authentication failures
A provider rejection can mean a bad key, wrong environment, missing IP allowlisting, unapproved production access or a wrong endpoint. Test those boundaries separately before changing application validation logic.
Primary sources
External technical details referenced on this page are linked to their original publisher.
Frequently asked questions
Can supplier credentials be exposed to frontend code?+
No. Supplier secrets should remain server-side and should never be embedded in browser bundles or public repositories.
Why can a correct key still fail?+
The key may belong to another environment, require supplier-side activation or be restricted to allowlisted outbound IPs.
Does connected status prove the credentials work?+
No. Readiness should require credential presence and a verified provider workflow, not only a metadata status.