Skip to main content
Server-only
This page covers your server webhook handler. The client triggers delegation; your server verifies, decrypts, and stores materials.
When a delegation is triggered, your endpoint receives a webhook named wallet.delegation.created. The delegated materials are in data.

Verify → Decrypt → Store

  1. Verify the webhook signature. See Validate webhook signatures.
  2. Decrypt data.encryptedDelegatedShare and data.encryptedWalletApiKey.
  3. Store userId, walletId, and decrypted materials securely (e.g., envelope encryption, KMS, at-rest encryption).
Encryption fields
alg: hybrid (RSA‑OAEP + AES‑256‑GCM); iv: AES IV; ct: ciphertext; tag: GCM tag; ek: encrypted content‑encryption key; kid: key identifier for rotation.

Example: Node (using Dynamic SDK)

If your server is Node.js, the easiest approach is to use our SDK helper which handles all the decryption logic for you:

Manual Decryption (any language)

If you don’t use Node.js, you can decrypt the materials yourself in any language that supports standard crypto primitives. The encryption scheme is hybrid RSA-OAEP + AES-256-GCM. Here’s a reference implementation in TypeScript:
Steps to replicate in your language of choice:
  1. Base64url-decode the ek field
  2. RSA-OAEP decrypt (SHA-256) the decoded ek using your private key — this gives you the AES content-encryption key
  3. Base64url-decode iv, ct, and tag
  4. AES-256-GCM decrypt using the content-encryption key, IV, ciphertext, and auth tag
  5. Repeat for both encryptedDelegatedShare and encryptedWalletApiKey
If a delivery fails, you can replay it from the dashboard. Use the eventId as an idempotency key.

Best Practices for Secure Storage

After decrypting the delegated materials, proper storage is critical. The delegatedShare and walletApiKey, in combination with your Dynamic developer API key, provide full signing authority and must be protected with defense-in-depth strategies.
Similar to AWS KMS, but integrated with Google Cloud’s ecosystem.
Microsoft Azure’s managed secrets and key management service.

Security Requirements Checklist

Regardless of your storage method, follow these requirements:
  • Never log plaintext materials — redact delegatedShare and walletApiKey from all logs, error messages, and monitoring
  • Encrypt at rest — use AES-256-GCM or equivalent; ensure database/storage has encryption enabled
  • Encrypt in transit — all communication must use TLS 1.3
  • Implement access controls — restrict which services and roles can decrypt materials
  • Enable audit logging — track all access to encrypted materials with timestamps and actor identity
  • Separate encryption keys — don’t reuse keys across environments (dev/staging/prod)
  • Use unique encryption per record — generate new IVs for each encryption operation
  • Implement key rotation — rotate encryption keys periodically (e.g., every 90 days)
  • Plan for key compromise — document incident response for key material exposure
  • Secure deletion — overwrite secrets in memory after use; use secure deletion for storage

Storage Schema Example

What NOT to Do

  • Never store plaintext shares in databases, files, or environment variables
  • Never commit encryption keys or shares to version control
  • Never use the same encryption key across all users
  • Never skip signature verification before storing materials
  • Never rely solely on database encryption without application-level encryption
  • Never expose decrypted materials through APIs or logs

What's next?

Learn how to use the delegated materials in Developer Actions.
Last modified on March 30, 2026