Verified history
This means HyperObserve has not found sufficient first-party evidence for a dated before-and-after event. It does not mean SendGrid has never changed. Undated values are kept in the current baseline below instead of being presented as history.
Current monitored baseline
HyperObserve currently monitors 3 scoped observations for SendGrid. The baseline covers total message size, recipients per Mail Send request, endpoint-specific API rate. Each value retains its plan, product, endpoint, region, account, or runtime qualifier so a future change can be compared against the correct scope.
| Constraint | Current value | Scope | Verified source |
|---|---|---|---|
| total message sizeThe complete request message, including encoded attachments, must remain below the ceiling. | Less than 30 MB | Mail Send API | Twilio SendGridAug 22, 2026 |
| recipients per Mail Send requestThe reply_to_list also has a documented 1,000-entry limit. | 1,000 | Mail Send API | Twilio SendGridAug 22, 2026 |
| endpoint-specific API rateSendGrid documents 429 handling without publishing one universal number for every endpoint. | Endpoint specific; exposed in rate-limit headers | v3 API | Twilio SendGridAug 22, 2026 |
Tracked constraints and impact
Mail Send payload, recipient, custom-argument, and endpoint rate limits. A change is recorded only when it alters a constraint developers can act on, such as capacity planning, request shaping, model selection, deployment configuration, storage design, retry behavior, or account budgeting.
SendGrid Mail Send Message Size Limit
SendGrid Mail Send Message Size Limit, verified against SendGrid's official documentation with scope, implementation impact, caveats, and a direct check.
SendGrid Recipient Limit per Request
SendGrid Recipient Limit per Request, verified against SendGrid's official documentation with scope, implementation impact, caveats, and a direct check.
SendGrid API Rate-Limit Headers
SendGrid API Rate-Limit Headers, verified against SendGrid's official documentation with scope, implementation impact, caveats, and a direct check.
How a change is verified
- Compare the current first-party statement with the previously stored observation, including the exact plan, model, runtime, endpoint, region, and account scope.
- Separate a true product change from documentation clarification, temporary capacity, configurable account state, or a limit that applies to a different execution path.
- Preserve the old and new values, official source, effective date when disclosed, detection date, and practical impact. If those elements cannot be supported, no historical event is published.
Official sources monitored
These first-party documents support the current SendGrid baseline. HyperObserve links directly to them so you can confirm the live wording before making a production decision.
Message size, recipient, reply-to, and custom-argument limits
Endpoint headers and 429 handling