Skip to content

docs: add POST /api/notifications endpoint#48

Merged
sweetmantech merged 8 commits into
mainfrom
sweetmantech/myc-4333-docs-post-apinotifications-follow-the-mcp-tool-definition
Feb 25, 2026
Merged

docs: add POST /api/notifications endpoint#48
sweetmantech merged 8 commits into
mainfrom
sweetmantech/myc-4333-docs-post-apinotifications-follow-the-mcp-tool-definition

Conversation

@sweetmantech

@sweetmantech sweetmantech commented Feb 25, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Add POST /api/notifications endpoint documentation following the send_email MCP tool definition
  • Supports to, cc, subject, text (Markdown), html, custom headers, and room_id for chat footer links
  • Add CreateNotificationRequest and NotificationResponse schemas to OpenAPI spec
  • Add Notifications group to docs navigation

Test plan

  • Preview docs locally with npx mintlify@latest dev
  • Verify the endpoint renders correctly with request/response schemas
  • Verify navigation shows Notifications group

🤖 Generated with Claude Code

Mintlify

0 threads from 0 users in Mintlify

  • No unresolved comments

Open in Mintlify Editor

Summary by CodeRabbit

Release Notes

  • New Features

    • New API endpoint for sending notifications with support for recipients, custom subjects, and message content in multiple formats.
  • Documentation

    • Added comprehensive API reference documentation for the notification endpoint, including complete request and response schema details.

Add notification email endpoint documentation following the send_email
MCP tool definition. Supports to, cc, subject, text (Markdown), html,
custom headers, and room_id for chat footer links.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Feb 25, 2026

Copy link
Copy Markdown

Warning

Rate limit exceeded

@sweetmantech has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 0 minutes and 6 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 846c513 and df41713.

📒 Files selected for processing (3)
  • api-reference/openapi.json
  • docs.json
  • sdk.mdx
📝 Walkthrough

Walkthrough

This PR introduces documentation and specification for a new notification API endpoint (POST /api/notifications) that sends notification emails via the Resend API. It adds OpenAPI schema definitions for the request and response payloads, a reference documentation page, and updates navigation configuration.

Changes

Cohort / File(s) Summary
OpenAPI Specification
api-reference/openapi.json
Added POST /api/notifications endpoint with CreateNotificationRequest schema (recipient, subject, message details) and NotificationResponse schema (success metadata with email ID).
Documentation & Navigation
api-reference/notifications/create.mdx, docs.json
Added new API reference page for the notification endpoint and registered it in the API reference navigation group.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A notification API hops into place,
With schemas defined and docs full of grace,
The Resend service receives our call,
For emails delivered to one and to all! 📨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The pull request title accurately and concisely summarizes the main change: adding documentation for the POST /api/notifications endpoint.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch sweetmantech/myc-4333-docs-post-apinotifications-follow-the-mcp-tool-definition

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
api-reference/openapi.json (1)

3916-3935: Define required fields in NotificationResponse for stable generated types.

Without a required array, all response properties are optional in generated SDKs.

Suggested schema tightening
       "NotificationResponse": {
         "type": "object",
+        "required": ["success", "message", "id"],
         "properties": {
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@api-reference/openapi.json` around lines 3916 - 3935, The
NotificationResponse schema currently leaves all properties optional which
weakens generated types; update the "NotificationResponse" OpenAPI schema to
include a "required" array listing the fields that must always be present (e.g.,
"success", "message", and "id") so SDKs and validators will treat those
properties as non-optional; modify the JSON definition for the
NotificationResponse object to add the required entry while keeping existing
property descriptions and examples intact.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@api-reference/openapi.json`:
- Around line 3866-3915: The CreateNotificationRequest schema currently allows
an empty recipient list and payloads without a body; update the
CreateNotificationRequest object to require a non-empty "to" array (add
"minItems": 1 to the "to" property) and enforce that at least one message body
is provided by adding an anyOf (or oneOf) at the object level that requires
either "text" or "html" (e.g., anyOf:
[{"required":["text"]},{"required":["html"]}]). Keep "to" and "subject" as
required but add these schema keywords to ensure valid recipients and
message-body invariants.

---

Nitpick comments:
In `@api-reference/openapi.json`:
- Around line 3916-3935: The NotificationResponse schema currently leaves all
properties optional which weakens generated types; update the
"NotificationResponse" OpenAPI schema to include a "required" array listing the
fields that must always be present (e.g., "success", "message", and "id") so
SDKs and validators will treat those properties as non-optional; modify the JSON
definition for the NotificationResponse object to add the required entry while
keeping existing property descriptions and examples intact.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 90ac1f6 and 846c513.

📒 Files selected for processing (3)
  • api-reference/notifications/create.mdx
  • api-reference/openapi.json
  • docs.json

Comment on lines +3866 to +3915
"CreateNotificationRequest": {
"type": "object",
"required": ["to", "subject"],
"properties": {
"to": {
"type": "array",
"items": {
"type": "string",
"format": "email"
},
"description": "Recipient email addresses",
"example": ["user@example.com"]
},
"cc": {
"type": "array",
"items": {
"type": "string",
"format": "email"
},
"description": "Optional CC email addresses",
"example": ["cc@example.com"]
},
"subject": {
"type": "string",
"description": "Email subject line",
"example": "Weekly Pulse Report"
},
"text": {
"type": "string",
"description": "Plain text or Markdown body. Rendered as HTML via Markdown if no `html` is provided.",
"example": "# Pulse Report\n\nHere's your weekly summary."
},
"html": {
"type": "string",
"description": "Raw HTML body. Takes precedence over `text` when both are provided.",
"example": "<h1>Pulse Report</h1><p>Here's your weekly summary.</p>"
},
"headers": {
"type": "object",
"additionalProperties": {
"type": "string"
},
"description": "Optional custom email headers"
},
"room_id": {
"type": "string",
"description": "Room ID to include a chat link in the email footer"
}
}
},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Enforce message-body and recipient invariants in CreateNotificationRequest.

The schema currently permits payloads with to + subject but no text/html, and also allows an empty to array. That under-specifies valid requests.

Suggested schema fix
       "CreateNotificationRequest": {
         "type": "object",
         "required": ["to", "subject"],
+        "anyOf": [
+          { "required": ["text"] },
+          { "required": ["html"] }
+        ],
         "properties": {
           "to": {
             "type": "array",
+            "minItems": 1,
             "items": {
               "type": "string",
               "format": "email"
             },
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@api-reference/openapi.json` around lines 3866 - 3915, The
CreateNotificationRequest schema currently allows an empty recipient list and
payloads without a body; update the CreateNotificationRequest object to require
a non-empty "to" array (add "minItems": 1 to the "to" property) and enforce that
at least one message body is provided by adding an anyOf (or oneOf) at the
object level that requires either "text" or "html" (e.g., anyOf:
[{"required":["text"]},{"required":["html"]}]). Keep "to" and "subject" as
required but add these schema keywords to ensure valid recipients and
message-body invariants.

sweetmantech and others added 7 commits February 25, 2026 07:56
The recipient email is now automatically resolved from the
authenticated account's API key or Bearer token.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
First SDK/CLI documentation page. Documents the notifications command
usage, options, examples, and its API equivalent.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Document the @recoupable/cli package with installation, auth setup,
and headings for all commands: whoami, artists, chats, sandboxes,
orgs, and notifications.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@sweetmantech sweetmantech merged commit db6c321 into main Feb 25, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant