Base URLs
| Service | URL |
|---|---|
| API | https://embed.nova.dweet.com/v1 |
| Dashboard | https://embed.nova.dweet.com/dashboard |
API Keys
Your API key determines the environment—use the same URL for both:| Key Format | Environment | Billing |
|---|---|---|
sk_test_<random> | Sandbox | Free, not billed |
sk_live_<random> | Production | Billed per score |
Required Headers
Every API request must include:Example Request
Tenant Header
TheX-Tenant-Id header identifies which of your customers the request is for:
Tenants are created automatically on first request. No pre-registration required.
- Your internal customer/account ID
- A UUID you generate for each customer
- Their subdomain or unique slug
Key Rotation
Rotate API keys without downtime:1
Create New Key
Generate a new key in the Embed Portal. Your old key remains active.
2
Deploy
Update your systems to use the new key.
3
Revoke Old Key
Once all systems are updated, revoke the old key.
Security Best Practices
Store keys securely
Store keys securely
Never commit API keys to source control. Use environment variables or a secrets manager.
Use separate keys per environment
Use separate keys per environment
Use sandbox keys for development/staging and production keys only in production.
Rotate keys periodically
Rotate keys periodically
Even without a suspected compromise, rotate keys every 90 days as a best practice.
Monitor key usage
Monitor key usage
Check the Embed Portal for unusual activity patterns.
Compromised Key Response
If you suspect a key is compromised:- Immediately revoke the compromised key in the Embed Portal
- Generate a new key and deploy it to your systems
- Review logs for unauthorized access
Error Responses
| Status | Code | Description |
|---|---|---|
| 401 | UNAUTHORIZED | Missing or invalid API key |
| 403 | FORBIDDEN | Valid key but insufficient permissions |
Example 401 Response
API Versioning
The API uses URL-based versioning. The current version isv1.
| Principle | Commitment |
|---|---|
| Stability first | No breaking changes to v1 |
| Additive evolution | New fields and endpoints added without version bump |
| Deprecation notice | If v2 is ever needed, 12+ months notice before v1 retirement |
What’s considered breaking?
| Breaking (requires new version) | Non-breaking (same version) |
|---|---|
| Removing or renaming fields | Adding new optional fields |
| Changing field types | Adding new endpoints |
| Changing error codes | Adding new optional parameters |
| Changing endpoint behavior | Adding new enum values |
We believe in API stability. We commit to evolving v1 additively and only creating v2 for fundamental architectural changes—which we have no plans for.