OtesseOtesseDocs

Security Best Practices

Follow these guidelines to keep your Otesse integration secure and protect customer data.

API Key Security

Do

  • Store API keys in environment variables or a secrets manager
  • Use different keys for development, staging, and production
  • Rotate keys every 90 days
  • Use the minimum required scopes for each key
  • Revoke keys immediately if compromised

Do Not

  • Commit keys to version control (even private repos)
  • Include keys in client-side JavaScript or mobile apps
  • Share keys via email, chat, or documentation
  • Log API keys in application logs
  • Use production keys in development environments

Detection

Add a pre-commit hook to catch accidentally committed keys:

#!/bin/bash
# .git/hooks/pre-commit
if git diff --cached | grep -E 'otesse_(live|test)_sk_'; then
  echo "ERROR: Otesse API key detected in commit. Remove it before committing."
  exit 1
fi

Webhook Security

Always Verify Signatures

Never process a webhook without verifying the HMAC-SHA256 signature:

// WRONG — never skip verification
app.post('/webhook', (req, res) => {
  processEvent(req.body); // INSECURE
});

// RIGHT — always verify first
app.post('/webhook', (req, res) => {
  if (!verifySignature(req)) {
    return res.status(401).send('Invalid');
  }
  processEvent(req.body);
});

Validate Event Origin

Only accept webhooks from Otesse IP ranges. Contact support for the current IP allowlist.

Use HTTPS

Your webhook endpoint must use HTTPS. Never accept webhooks over plain HTTP.

Data Handling

Minimize Data Storage

Only store the Otesse data you actually need. If you only need booking IDs for reconciliation, do not store full customer profiles.

Encrypt at Rest

If you store customer data from Otesse, encrypt it at rest:

  • Database encryption (AES-256)
  • File encryption for exports and backups
  • Key management using a proper KMS

Access Control

Restrict who and what can access Otesse data in your system:

  • Role-based access control for team members
  • Service accounts with limited permissions for automated processes
  • Audit logging for all data access

Common Pitfalls

1. Exposing Secret Keys in Frontend Code

API keys starting with sk are secret keys. Only use them server-side. For client-side integrations, use the public embed key (pk).

2. Not Handling Expired Tokens

OAuth access tokens expire after 1 hour. Implement automatic refresh to avoid disruptions.

3. Logging Sensitive Data

Be careful not to log:

  • API keys or tokens
  • Customer payment information
  • Full request/response bodies that contain PII

4. Insufficient Error Handling

Do not expose Otesse API error details to end users. Log the full error internally but show generic messages to users.

5. Missing Rate Limit Handling

Without proper rate limit handling, your integration can fail silently. Always implement retry with backoff for 429 responses.

Compliance

If your integration handles customer data, you may need to comply with:

  • PCI DSS — If handling payment data (use Stripe Elements to avoid this)
  • GDPR — If serving EU customers (implement data deletion on request)
  • CCPA — If serving California customers (support data access requests)
  • SOC 2 — If you are a SaaS provider handling Otesse data

Otesse is PCI DSS Level 1 compliant and SOC 2 Type II certified. Your integration should maintain equivalent standards for any data it stores.

JavaScript SDKEnvironment Setup