feat: add get-campaigns docs

[magicspon]

Adds the missing API reference documentation for get /v1/campaigns

---

Summary by cubic

Adds the missing API reference for GET /v1/campaigns with pagination, filtering, and response schema. Addresses the Linear issue about missing get-campaigns docs.

• New Features
  • Documents GET /v1/campaigns query params: page (default 1), status (DRAFT|SCHEDULED|IN_PROGRESS|PAUSED|COMPLETED|CANCELLED), search.
  • Defines 200 response: campaigns[] with id, name, from, subject, createdAt, updatedAt, status, scheduledAt (nullable), total, sent, delivered, unsubscribed; plus totalPage.

^{Written for commit 1d1216a. Summary will update on new commits.}

Summary by CodeRabbit

Release Notes

• New Features
  • Added a new endpoint to list campaigns with pagination and filtering capabilities
  • Filter campaigns by status or search term to find specific campaigns
  • Campaign list includes details such as name, status, dates, and delivery metrics

[vercel]

@magicspon is attempting to deploy a commit to the kmkoushik's projects Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

Walkthrough

This pull request adds a new GET endpoint specification to the OpenAPI documentation for /v1/campaigns. The endpoint enables listing campaigns with support for pagination through a page parameter (default: 1), status filtering via an enum (DRAFT, SCHEDULED, IN_PROGRESS, PAUSED, COMPLETED, CANCELLED), and text-based search. The response includes a campaigns array containing campaign objects with fields such as id, name, from, subject, createdAt, updatedAt, status, scheduledAt, and delivery metrics (total, sent, delivered, unsubscribed), along with a totalPage field.

Possibly related PRs

• feat: v1/campaign public api endpoint #335: Implements the server-side route for the same GET /v1/campaigns endpoint with identical query parameters and response schema.

Suggested reviewers

• KMKoushik

🚥 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 title accurately describes the main change: adding API documentation for the GET campaigns endpoint. It is specific, concise, and directly related to the changeset.
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.}

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

apps/docs/api-reference/openapi.json (1)

1764-1764: Response status field lacks the enum constraint present on the query parameter.

The status query parameter (line 1722) correctly lists the enum values (DRAFT, SCHEDULED, etc.), but the status property in the response campaign object is a bare "type": "string". Adding the same enum here improves documentation for API consumers and enables better client code generation.

Proposed fix

-"status": { "type": "string" },
+"status": {
+  "type": "string",
+  "enum": [
+    "DRAFT",
+    "SCHEDULED",
+    "IN_PROGRESS",
+    "PAUSED",
+    "COMPLETED",
+    "CANCELLED"
+  ]
+},

Note: the same bare "type": "string" pattern exists for status in the POST /v1/campaigns and GET /v1/campaigns/{campaignId} response schemas (lines 1870 and 1961), so this is a pre-existing gap — but worth fixing while you're here.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[cubic-dev-ai]

No issues found across 1 file

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds an OpenAPI GET /v1/campaigns operation under apps/docs/api-reference/openapi.json, documenting pagination (page), filtering (status), and search, along with a 200 response schema returning an object with campaigns[] and totalPage.

The change fits into the existing docs repo pattern where API endpoints are described directly in paths within a single OpenAPI JSON used to render the docs and drive any client/type generation.

Confidence Score: 4/5

• Mostly safe to merge, but the OpenAPI schema has a couple mismatches that should be corrected to avoid inaccurate docs/client generation.
• Only documentation/schema changes are included, but the page parameter is typed as a string (should be integer) and the campaign status response field lacks the enum constraints already documented elsewhere, which will lead to inconsistent API reference output and generated types.
• apps/docs/api-reference/openapi.json

[greptile-apps]

_{1 file reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Wrong type for page

page is documented as a string ({"type":"string","default":"1"}), but it represents a page number. This will generate incorrect client types and allows non-numeric values. It should be an integer (optionally with minimum: 1) and defaults/examples should be numeric.

Suggested change

	{
	"schema": { "type": "string", "default": "1", "example": "1" },
	"required": false,
	"schema": { "type": "integer", "minimum": 1, "default": 1, "example": 1 },

[greptile-apps]

Enum missing for status

In the 200 response schema, each campaign’s status is currently just {"type":"string"}. Since you already define the allowed values in the status query param, leaving the response unconstrained will produce weaker/incorrect generated types and inconsistent docs. Consider adding the same enum to the response field.

Suggested change

	"status": { "type": "string" },
	"scheduledAt": { "type": "string", "nullable": true, "format": "date-time" },
	"total": { "type": "integer" },
	"status": { "type": "string", "enum": ["DRAFT","SCHEDULED","IN_PROGRESS","PAUSED","COMPLETED","CANCELLED"] },