Security & abuse prevention

Transport and credentials

• HTTPS in production — the SDK enforces https for the primary base URL (localhost http allowed in dev only with an explicit flag).
• Bearer API keys — long-lived partner keys are used only in server-to-server calls; they must not be embedded in web or mobile clients, reducing leak surface. Same pattern as other integration docs that separate publishable and secret material (e.g. Stripe’s key model).

Webhooks

• HMAC-SHA256 with a shared secret, a timestamp window to reject stale replays, and timing-safe comparison of digests (see verifyWebhookSignature in anemone-server-js). Details: Webhooks.

User accounts in the Anemone app

The product uses Clerk for authentication. Production requires multi-factor authentication (MFA) via Clerk (authenticator app / TOTP). Users without MFA are guided through enrollment before their session becomes active, and Plaid Link is not surfaced until MFA is enrolled. Sensitive flows (such as approving contact update requests) also use Clerk reverification at the moderate level so users re-confirm their credentials within about an hour before changes apply.

Global vs pending updates

Pushing a contact update is one step: the platform may return pending_user_review until a user confirms, or rejected when policy is not met. Certified integrations, combined with user auth and in-product consent, are required before changes are treated as globally authoritative for downstream merchants.

Operational hardening (recommended for partners)

• Store secrets in a vault or environment manager; rotate API keys on schedule.
• Use idempotency keys on outbound updates to avoid duplicate effects.
• Log correlationId from API responses for incident response.

For signing algorithms and error types, read anemone-server-js src/webhook.ts and src/client.ts in your local checkout.

Return to home