Go Live

Once your staging integration is working end-to-end (authenticate, fetch brands, place orders, handle all statuses), it's time to transition to production.

---

Production Credentials

Hubble provides production credentials separately from staging. You will receive new clientId and clientSecret for production (different from staging).

Credential Isolation

Staging credentials do not work on production. Each environment has its own credentials. Update both the base URL and credentials when switching to production.

Environment Configuration

Setting	Staging	Production
Base URL	https://api.dev.myhubble.money	https://api.myhubble.money
clientId	Staging clientId	Production clientId
clientSecret	Staging secret	Production secret
IP Whitelisting	May not be required	Required

---

IP Whitelisting

Hubble only allows API requests from pre-approved IP addresses. Use the integration portal to add your server's static IPs.

Requirements

• Production server IPs must be whitelisted separately from staging
• Share your server's static IP addresses with Hubble
• Requests from non-whitelisted IPs will receive a 403 Forbidden error

If You See "Invalid Access"

1. Ensure the request is from a whitelisted IP
2. Confirm server IP has not changed since initial setup
3. Check if a VPN or proxy is routing traffic through a different IP
4. Confirm your outgoing IP matches exactly what was shared with Hubble

Dynamic IP Support

If your infrastructure uses dynamic IPs, inform Hubble during onboarding. In such cases, IP whitelisting is not required (similar to staging).

---

Rate Limiting

Rate limits protect both Hubble and your integration from abuse and ensure fair usage across all partners.

Rate Limit Levels

Limits are enforced at two levels:

Level	Scope	Description
Partner-level	Across your entire account	Total limits for all your API calls
Brand-level	Per product/brand	Limits specific to individual brands

Rate Limit Types

Type	Description	Time Windows
Amount	Total monetary value of orders	Hourly, Daily, Monthly
Count	Number of orders/requests	Hourly, Daily, Monthly

Brand-Level Scoping

Brand-level limits can be scoped:

• Globally — Total across all users
• Per user — For granular risk control per end-customer

Handling Rate Limit Failures

Important

Rate limit failures are business logic failures, not HTTP 429 errors. Always check the response body for the failure reason.

When a rate limit is exceeded:

{
  "id": "E400",
  "code": "RATE_LIMIT_EXCEEDED",
  "message": "Brand is temporarily unavailable, please try again later"
}

Best Practices

1. Define realistic limits before going live
2. Coordinate with Hubble ahead of high-volume campaigns or seasonal spikes
3. Monitor your usage to stay within limits
4. Implement backoff logic when approaching limits

---

Pre-Launch Checklist

Authentication

• Update base URL to production (https://api.myhubble.money)
• Configure production clientId and clientSecret
• Verify token management works with production credentials

IP Whitelisting

• Share production server IPs with Hubble
• Confirm IPs are whitelisted in the integration portal
• Test API access from production servers

Wallet

• Ensure production wallet has sufficient balance
• Set up Wallet Low Balance webhook with appropriate threshold
• Establish process for wallet top-ups

Webhooks

• Configure production webhook endpoints (separate from staging)
• Test webhook signature verification
• Confirm all required webhooks are set up:
  • Brand Updated
  • Wallet Low Balance
  • Order Reached Terminal State

Rate Limits

• Understand your allocated rate limits
• Implement monitoring for rate limit usage
• Plan for high-volume periods

Catalog

• Set up scheduled catalog sync (daily/weekly)
• Configure Brand Updated webhook handling
• Implement INACTIVE brand filtering

Error Handling

• Test handling of all order states (SUCCESS, FAILED, PROCESSING)
• Implement retry logic with new referenceIds
• Set up monitoring and alerting

---

Production Monitoring

Recommended Metrics

Metric	Why It Matters
Order success rate	Detect provider or integration issues early
Average response time	Identify performance degradation
Error rate by type	Understand failure patterns
Wallet balance	Prevent E300 errors
Webhook delivery rate	Ensure real-time updates are received

Alerting

Set up alerts for:

• Order success rate drops below threshold
• Wallet balance below minimum
• Error rate spikes
• Webhook delivery failures
• Rate limit approaching

---

Support

For production issues, contact Hubble support with:

1. X-REQUEST-ID — Critical for troubleshooting
2. Order ID or Reference ID
3. Timestamp of the issue
4. Error message or response body
5. Steps to reproduce (if applicable)

X-REQUEST-ID

Always log and retain the X-REQUEST-ID for every API call. This dramatically speeds up support resolution.