Skip to main content

​
Overview

Hacktionbase uses different authentication methods depending on where the interaction happens:
ContextMethodWho uses it
DashboardEmail / password loginYour team members
SDK / WidgetAutomatic (via identify)Your end-users — no credentials needed
Public APIAPI key (Bearer token)Your backend servers

​
SDK & widget authentication

When the SDK is initialized and you call identify(), Hacktionbase authenticates the end-user session automatically. There’s nothing extra to implement — the SDK handles the handshake with the widget behind the scenes. 
Hacktionbase.identify({
  id: 'user_123',
  email: 'jane@example.com',
  name: 'Jane Doe'
});
  • Sessions are scoped to a single workspace and user
  • Tokens are short-lived and automatically refreshed
  • No user credentials are exposed to the browser

​
API key authentication

For server-side integrations, generate an API key from Settings → API Keys in the dashboard: 
curl -X POST https://api.hacktionbase.com/v1/events \
  -H "Authorization: Bearer hb_key_xxxxx" \
  -H "Content-Type: application/json" \
  -d '{"event": "signup", "userExternalId": "user_123"}'
  • Each API key is scoped to a single workspace
  • Keys can be rotated at any time from the dashboard
  • Use API keys only on your backend — never expose them in client-side code

​
Identity verification (HMAC)

For security-sensitive applications, you can enable HMAC identity verification to prevent users from impersonating others via the SDK. When enabled, your backend signs the user ID with a secret, and the SDK passes the signature during identify(). See Widget Authentication for implementation details.

​
Security summary

  • All tokens are signed and tamper-proof
  • Sessions are isolated per workspace and per user
  • API keys and SDK keys cannot access other workspaces
  • Short-lived tokens limit the blast radius of any leak