Vetrix Docs

Naming doctrine: /merges canonical

The user-facing merge-request API surface is /api/v1/repos/{owner}/{repo}/merges/**. This document captures the naming convention.

Routing rules

  • /api/v1/repos/{owner}/{repo}/merges/** routes mirror the /pulls/** handlers. All new client code, docs, and examples must use /merges/.
  • /api/v1/repos/{owner}/{repo}/pulls/** redirects to the equivalent /merges/** URL with HTTP 308 (method-preserving permanent redirect; method and query string preserved per RFC 7538). /pulls/** is retained only for back-compat with existing integrations; do not add new functionality under /pulls/, and do not document it as canonical.

Wire-level identifiers (preserved as-is)

The following identifiers are wire-level constants and must NOT be renamed:

  • DB table name: merge_requests — schema compatibility.
  • Webhook event name: pull_request — webhook payload compatibility for existing subscribers.
  • WebSocket route: /ws/repos/{owner}/{repo}/pulls/{number} — preserved as a separate wire-level identifier (not redirected; clients connect to this exact path).

These are not user-facing copy and should not be "renamed" to match the UI vocabulary.

User-facing copy

User-facing copy in docs, CLIs, and UIs says "merge request" / "MR" — never "pull request". Vetrix's CI feature is "Vetrix Workflows" (proper noun) or lowercase "pipeline" / "workflow". Do not call it "Actions" or "GitHub Actions". "Actions" as a UI table-column header for row affordances is a different word with the same spelling — keep that.