API Auth
- Paymish
- API Auth
API Auth
Authenticate partner systems and exchange credentials for the tokens or secure access values required for subsequent API calls.
Endpoints
1 endpoint in this collection.
Authentication
Review each endpoint for its auth requirement before implementation.
What this section covers
- Generate an access token before calling protected endpoints.
- Validate partner or merchant credentials during onboarding.
- Bootstrap server-to-server integrations safely.
Method mix
Collect the required credentials from the Paymish Dashboard or integration setup.
Send them to the authentication endpoint over HTTPS from your backend.
Store the returned token securely and attach it to subsequent protected requests.
Prerequisites
- Confirm you have the correct Paymish secret or partner credentials for the environment you are integrating against.
- Decide where your backend will store active tokens, expiry timestamps, and refresh state if token rotation is required.
- Make sure every downstream API client can inject the generated bearer token without duplicating auth logic.
Implementation Checklist
- Keep credential exchange strictly server-side.
- Add token refresh handling before protected requests fail in production traffic.
- Log auth failures with safe metadata only, never with raw secrets or full tokens.
Success Signals
- Token generation succeeds consistently from backend-only flows.
- Protected endpoint calls stop failing with unauthorized responses caused by missing auth state.
- Support teams can trace which service or merchant context produced a token without exposing secrets.
Common Pitfalls
- Calling auth endpoints directly from frontend code or mobile apps where secrets can be exposed.
- Treating token generation as a one-time setup instead of handling expiry, refresh, and retry behavior.
- Allowing each service to implement auth independently, which leads to inconsistent headers and poor observability.
Operational Notes
- Centralize auth in one internal client so downstream services reuse the same header construction and renewal behavior.
- Alert on sudden spikes in unauthorized responses because they often indicate expired tokens, rotated credentials, or deployment drift.
- Separate sandbox and production secrets clearly in your configuration so environments cannot be mixed accidentally.
Each endpoint below links to a fuller implementation guide with request structure, code examples, and response notes.
Python
Wrap token generation and renewal inside one shared client so Celery jobs, cron tasks, and backend services all reuse the same auth path.
Node.js
Keep auth exchange inside server-side code only, then expose a higher-level Paymish service module to the rest of your Node.js app.
PHP
Store tokens in a reusable service class and refresh them centrally so controllers do not rebuild auth state on every request.
cURL
Use cURL only for verification and troubleshooting, not as the model for where secrets should live in a production integration.