System Capacity Overview
Our API infrastructure is designed to handle:
- Request Rate: 150-200 requests per second
- Data Throughput: 135-180 MB per second
- Architecture: Load-balanced across multiple servers
Best Practices for API Integration
1. Implement Rate Limiting
To ensure optimal performance for all users, please implement client-side rate limiting:
Recommended approach:
- Maximum 100 requests per second per client
- If you have multiple integration points, distribute the load across them
- Use exponential backoff when receiving rate limit errors (HTTP 429)
2. Avoid Traffic Bursts
Problem: Sending thousands of messages simultaneously during peak hours can overwhelm our infrastructure and cause:
- Request timeouts
- Failed API calls
- Degraded performance for all customers
Solution: Implement request queuing and throttling
Example pattern:
- Queue your messages locally
- Send at a steady rate of 50-100 requests/second
- Monitor response times and adjust accordingly
3. Optimize Peak Hour Operations
If you need to send large volumes during morning hours:
- Spread the load: Start sending 30-60 minutes before your target completion time
- Batch wisely: Keep batch sizes reasonable (recommend 100-500 items per batch)
- Use asynchronous processing: Implement async patterns where messages don't need immediate confirmation
4. Monitor and Respect HTTP Response Codes
| Code |
Meaning |
Action |
| 429 |
Too Many Requests |
Wait and retry with exponential backoff (start with 1s, then 2s, 4s, etc.) |
| 503 |
Service Unavailable |
Temporary overload - retry after 30-60 seconds |
| 500-504 |
Server Error |
Retry up to 3 times with delays |
5. Payload Optimization
- Keep individual request payloads under 1 MB when possible
- Compress large payloads when your use case allows
- Remove unnecessary data fields from requests
6. Connection Management
- Use persistent connections (HTTP keep-alive) to reduce overhead
- Implement connection pooling (recommend 5-10 connections per client)
- Set reasonable timeout values (suggest 30 seconds for read timeout)
Recommended Implementation Example
Rate limiter configuration:
- Requests per second: 80-100
- Burst allowance: 150 (short spike tolerance)
- Retry strategy: Exponential backoff starting at 1 second
- Max retries: 3 attempts
Need Higher Capacity?
If your business requirements exceed these guidelines, please contact our tech team to discuss:
- Dedicated infrastructure options
- Custom rate limits
Support Contact
For technical questions or capacity planning assistance, reach out to our technical support team with your:
- Expected request volume
- Peak usage patterns
- Current integration approach
Note: Following these guidelines ensures reliable service for your application and maintains system stability for all our customers.
Potential API Response Codes
1. Standard API Response
APIResponse | SendMessageResponseType
| Parameter |
Description |
| String smtpId |
SMTP message ID of the sent message |
| String message |
Information of the request |
| int code |
0: success 1: authentication failed 2: address error 3: other error 4: other error |
| boolean success |
whether action is successful |
Example response:
{
"smtpId": "<1006462692.13.1775588067812.JavaMail.root@1342438-rs5r8.max.md>",
"message": "Message sent. Message was sent and saved to INBOX.Sent folder",
"code": 0,
"success": true
}
2. Implementer Configuration or Business Errors (MaxMD Service is Up and Running)
Sometimes the implementer will see:
HTTP 200 OK
{
"code": 999,
"message": "error"
}
This means:
- Server is up
- Application is running
- But the request from the implementer's system failed at the configuration, implementation or business logic level
3. MaxMD API Issue (application is running but there is an internal issue)
- 500 Internal Server Error: this means the application crashed or threw an unhandled exception
4. MaxMD Server Issue (MaxMD Scheduled Maintenance / MaxMD network or infrastructure issue)
Case A: Service Interruption (no response at all)
- Implementer would get no HTTP status code returned
- Implementer would see errors such as:
- Connection refused
- Timeout
- DNS resolution failed
- This means the MaxMD messaging service is unreachable.
Case B: Load balancer or gateway issues
Implementer would see:
- 502 Bad Gateway: this means the back-end service is down or not responding correctly
- 503 Service Unavailable: this means the service is currently unavailable or in maintenance
- 504 Gateway Timeout: this means the back-end didn't respond in time