Errors, Types & Migration
Error Handling
All SDK methods reject with a PartnerConnectError (a real Error subclass) carrying both code and message. The legacy LearnCardError shape is preserved — error.code keeps working — so existing call sites continue to function unchanged:
import { PartnerConnectError } from '@learncard/partner-connect';
try {
await learnCard.requestLearnerContext();
} catch (err) {
if (err instanceof PartnerConnectError) {
// Type-narrowed: TypeScript knows err.code: ErrorCode
switch (err.code) {
case 'LC_UNAUTHENTICATED':
showLogin();
break;
case 'USER_REJECTED':
showPrivacyNotice();
break;
case 'UNAUTHORIZED':
showPermissionsError();
break;
default:
console.error(err);
}
}
}The LearnCardError interface remains exported for backwards compatibility:
Error Codes
LC_TIMEOUT
Request timed out
LC_NOT_EMBEDDED
Not embedded in a LearnCard host (standalone, not mocking)
LC_UNAUTHENTICATED
User not logged in
USER_REJECTED
User declined the request
CREDENTIAL_NOT_FOUND
Requested credential doesn't exist
UNAUTHORIZED
User lacks permission
TEMPLATE_NOT_FOUND
Template doesn't exist
SDK_NOT_INITIALIZED
SDK not properly initialized
SDK_DESTROYED
SDK was destroyed before completion
Error Handling Patterns
Advanced Configuration
Multiple Origins (Staging Support)
Native App Support
For Capacitor/Ionic apps:
Custom Timeouts
Migration Guide
From Manual postMessage
Before (80+ lines of boilerplate):
After (3 lines):
Benefits:
85% code reduction in typical integrations
Type safety with full TypeScript support
Better error handling with structured error codes
Security improvements with origin validation
No manual cleanup required
Examples
SSO Authentication Flow
Credential Gating (Premium Content)
Credential Issuance (Certificate Award)
TypeScript Types
All types are exported from the package for full type safety:
Key Type Definitions
Last updated
Was this helpful?