Sign-in
Single sign-on (SAML)
Connect Raindrop to your identity provider (Okta, Microsoft Entra ID, Google Workspace and other SAML 2.0 providers) so your team signs in with their work account. Disabling someone in your IdP then also blocks new sign-ins. SSO is part of the Enterprise plan. Contact us to turn it on, and we’ll walk your IdP admin through the setup.SCIM provisioning
With SCIM, your IdP creates, updates and removes Raindrop accounts for you. Assigning the Raindrop app to someone in your IdP adds them to the organization, and unassigning them removes them. You no longer have to remember to offboard people in Raindrop.Require two-factor authentication
If you aren’t using SSO, require two-factor authentication (2FA) for everyone in the organization:- Open Settings → Team and click Manage Team.
- Open Settings, and under Security settings turn on Everyone in this organization must enable 2FA.
Team access
Assign the member role to most users
- Owner can do everything, including rotating the write key and inviting other Owners. Keep this to two or three people.
- Admin manages settings, integrations, org-wide API keys and teammates.
- Member uses the product and can create personal API keys.
Limit who can join
On the same Manage Team → Settings page, under Membership settings:- Turn on Users without an @yourcompany.com email address cannot be invited, so nobody can invite a personal or outside address by mistake.
Review who has access
In Settings → Team, Owners can click Export CSV to download the member list for a quarterly access review. Remove anyone who has left or no longer needs access. With SCIM, do this in your IdP instead. When someone leaves, also revoke any org-wide API keys they created or had copies of (see below). Org-wide keys aren’t tied to a person, so removing the person doesn’t revoke them.API keys
Raindrop has two kinds of keys, both in Settings → API Keys.- The write key sends events and traces to Raindrop. It can’t read data back out.
- Query SDK keys read your data through the Query SDK, the Query API and MCP. These are the keys to guard most closely.
Set an expiry on Query SDK keys
When you create a Query SDK key, pick when it expires: 30 days, 90 days, 1 year or never. Use the shortest expiry that fits how the key is used, and avoid Never unless you have another process for rotating it.- Personal keys belong to you and follow your role. Use them for your own scripts and for MCP clients that can’t use OAuth.
- Org-wide keys are for CI and servers. Only Owners and Admins can create them. Give each one a name that says where it runs, so you know what breaks when you revoke it.
Limit the MCP and Query SDK to Owners and Admins
If only a few people need to read data out of Raindrop programmatically, turn on Limit to owners and admins under Who can use the MCP and Query SDK. With it on:- Only Owners’ and Admins’ personal keys work with the Query SDK and MCP.
- Org-wide keys, including those used in CI, get
403. - Members can no longer create keys.
Prefer OAuth for MCP clients
Claude Code, Cursor, VS Code, Windsurf and Codex can connect to the Raindrop MCP server with OAuth. OAuth signs in as the person using the editor, so access follows their account and there’s no long-lived key sitting in a config file. Use an API key only for clients that don’t support OAuth.Sensitive data
Redact PII
Turn on PII Guard in Settings → PII to strip PII from user and model messages when Raindrop receives them. Raindrop stores only the redacted text. To keep common PII from leaving your servers at all, also turn on local redaction in the TypeScript SDK.Only send what you need
Raindrop stores whatever you send. Before you add a field toproperties or user traits, ask whether you’d be comfortable with it in your own logs. Leave out secrets, auth tokens, and payment or health data.