Developers

Brehnor Communications (brehnorcomms) public API

This site exposes a small public REST surface for contact form submissions at /api/v1. Start at the brehnorcomms developer resources hub. Admin and CMS APIs are private and not documented here.

Contact submission

POST /api/v1/contact (alias POST /api/contact) accepts HTML form encoding (application/x-www-form-urlencoded or multipart/form-data) with the following fields:

  • firstName (required)
  • lastName (required)
  • email (required, valid email format)
  • message (required)
  • phone (optional)

Successful responses return JSON with { "success": true }. Errors use RFC 9457 application/problem+json: validation is 400, bot verification failure is 403, and rate limits return 429.

Versioning and deprecation

Canonical public REST is /api/v1. Responses include API-Version: 1. Breaking changes ship as /api/v2. Deprecation uses RFC 9745 Deprecation and RFC 8594 Sunset, with at least 90 days notice. Nothing is deprecated today.

Errors

Public REST errors are typed application/problem+json objects with type, title, status, detail, code, and hint. Problem types:

  • validation — 400 VALIDATION_ERROR
  • bot-verification — 403 BOT_VERIFICATION_FAILED
  • not-found — 404 NOT_FOUND
  • method-not-allowed — 405 METHOD_NOT_ALLOWED
  • rate-limited — 429 RATE_LIMITED
  • internal — 500 INTERNAL_ERROR

Rate limits

Responses include RateLimit and RateLimit-Policy (draft-ietf-httpapi-ratelimit-headers-11). Contact POSTs: 30 per hour per IP. Index GETs: 300 per hour per IP. A 429 includes Retry-After. Counters are per serverless isolate.

Bot Protection

In production, requests are checked with Vercel Bot Protection. Automated clients should expect that unauthenticated or bot-flagged requests may receive a 403 response. Legitimate browser-based submissions include the verification signals the platform expects.

Authentication

The public contact API is designed for browser form submissions, not OAuth 2.0 or OpenID Connect. There is no client credentials or authorization-code flow for this endpoint; in production, legitimate traffic must satisfy bot verification as described above.

This site does not publish /.well-known/openid-configuration or /.well-known/oauth-authorization-server because it does not operate an authorization server for third-party API clients.

Admin and CMS HTTP routes use private cookie-based sessions and are not part of this public API surface.

OpenAPI

A machine-readable OpenAPI 3 description of this endpoint is published at /openapi.json.

Discovery

Agent and machine discovery metadata is advertised via HTTP Link headers on the homepage (RFC 8288) and via /.well-known/api-catalog (RFC 9727)—an API catalog linkset, not OAuth authorization server metadata. This site also serves /.well-known/oauth-protected-resource (RFC 9728), which describes the resource identifier and optional authorization server issuers for token-based access when configured—it is not an authorization server and does not replace /.well-known/openid-configuration.

For Model Context Protocol discovery, this host publishes /.well-known/mcp/server-card.json (and the same payload at /.well-known/mcp/server-cards.json for tools that probe the plural path first) as draft SEP server card metadata, plus a minimal public MCP over Streamable HTTP at /api/mcp—read-only tools (site_info, ping) for site metadata and reachability. That endpoint is not the contact form and does not expose admin or CMS operations.

For Agent Skills discovery (RFC v0.2.0), this origin lists published skills and integrity digests at /.well-known/agent-skills/index.json. Skill artifacts live under /.well-known/agent-skills/; this is not OAuth authorization server metadata.