Security

Call the Developer API directly from infrastructure you control. Do not route production traffic through the CookBookr web app, and do not treat this like a key you embed in a public client.

Where keys belong

• Your backend server (Node, Python, Ruby, Go, etc.)
• A serverless function or API route you control
• Your mobile app only if the key stays on your server and the app talks to your backend first

Where keys do not belong

• Browser JavaScript, including React, Vue, or static sites
• Mobile apps that ship the key inside the installable app
• Public Git repos, screenshots, or shared Postman collections
• Client-side environment variables that end up in the user’s browser

Recommended integration pattern

Your app calls your backend. Your backend calls https://my.cookbookr.app/api/v1/developer/... with Authorization: Bearer cbk_your_key. That backend-for-frontend layer on your side is the right place to hold secrets, cache responses, and shape data for your UI.

What CookBookr enforces

• API keys are hashed at rest. We never store the full secret after you create a key.
• Read-only access to recipes authors have listed on their public recipe websites. No writes, no account data.
• Per-key rate limits: 60 requests per minute and 2,000 per hour.
• Abusive traffic from an IP address is blocked automatically. Revoke a compromised key from your dashboard anytime.

If a key leaks

Revoke it in your developer dashboard, create a replacement, and deploy the new secret on your server. Name keys by app so you can rotate one integration without touching the others. The try-it-out panel below is for manual testing only. Do not paste a production key into a shared browser session.