Client secret rules
Yourclient_secret is the most sensitive credential in your Connect integration. Treat it like a private key.
Never:
- Include it in frontend JavaScript or HTML
- Put it in a mobile app binary
- Commit it to version control (
.envfiles included) - Log it or send it in error reports
- Expose it in API responses
- Store it as an environment variable
- Use it only in server-side token exchange
- Rotate it immediately if you suspect it was exposed
State parameter (CSRF protection)
Always generate a freshstate value per authorization request and validate it on callback:
state validation, an attacker can trick a user’s browser into completing an OAuth flow the attacker controls.
Token storage
Store access and refresh tokens encrypted at rest. See the Token Management page for encryption helpers in Node.js and Python. Don’t store tokens in:- Browser
localStorageorsessionStorage - Unencrypted database columns
- HTTP cookies without
HttpOnlyandSecureflags
Handle 401 from user revocation
Users can revoke your app’s access from their Monei settings at any time. When this happens, any API call with that token returns401. Your app must handle this gracefully:
Production checklist
Before going live, confirm every item:Credentials
Credentials
-
client_secretis stored as an environment variable, not in code -
client_secretis not committed to version control - Separate credentials for dev and production environments
- Redirect URIs registered for production domain (not just localhost)
OAuth flow
OAuth flow
-
stateparameter generated fresh per request usingcrypto.randomBytesorsecrets.token_hex -
statevalidated on every callback before processing the code -
errorquery param handled on callback, user-friendly message shown - Token exchange happens server-side only
- Authorization code exchanged immediately after callback (expires in 10 minutes)
Token handling
Token handling
- Access tokens stored encrypted at rest
- Refresh tokens stored encrypted at rest
- Token expiry stored and checked before each API call
- Auto-refresh implemented with 5-minute buffer before expiry
-
401from API handled by clearing tokens and prompting reconnect - Token revocation called when user disconnects from your platform
Scope handling
Scope handling
-
scopesfield read from token response (not assumed from request) - Granted scopes stored per user
- UI disables or hides features the user hasn’t granted
- 403 from API handled gracefully, not shown as a raw error
- Re-authorization path built for upgrading individual scopes
Errors & Rate Limits
Full error reference and rate limit table

