Authentication
SenteRail uses different credential patterns for browser sessions, server-side API calls, sandbox traffic, and partner integrations. Keep every secret server-side and use the least powerful credential that supports your workflow.
Credential Types
| Credential | Used by | Where it belongs |
|---|---|---|
| Merchant session token | Merchant servers and dashboards after login | Server-side requests |
| Merchant API key | Server-to-server merchant integrations | Secret manager or backend runtime |
| Test API key | Sandbox integrations | Development secret store |
| Partner key | Approved partner integrations | Server-side partner systems |
| Webhook signing secret | Your webhook receiver | Backend verification code |
Product access depends on your SenteRail account and enabled products. Do not infer production access from a sandbox key.
Merchant Access
Merchant integrations commonly use one of two patterns:
- Use a merchant session token for authenticated dashboard-backed flows.
- Use
X-Merchant-Api-Keyfor server-to-server requests where your account supports direct API-key access.
Raw API keys should not appear in frontend code, mobile apps, browser logs, or public issue trackers.
Sandbox Access
Sandbox keys use the SenteRail test-key prefix. Use them only against sandbox or test endpoints. If a request fails because it requires a test key, confirm that your credential is not a live key.
Continue with Sandbox quickstart to run the first test payment and webhook flow.
Partner Access
Partner access is account-specific and subject to onboarding and commercial approval. Keep partner credentials server-side, rotate them through the agreed process, and verify which products are enabled before production testing.
Webhook Signing
SenteRail signs outbound webhooks so your system can verify authenticity before mutating state. Store the signing secret outside source control, reject stale timestamps, and dedupe event IDs.
Read Webhooks for signature verification and retry behavior.
Rotation Checklist
- Store keys in a secret manager or backend runtime.
- Rotate keys when a developer leaves, a vendor changes, or a secret appears in logs.
- Keep sandbox and live keys separate.
- Confirm webhook verification after each secret rotation.
- Keep one owner for production credential changes.