Add brewpage.app (hosting, developer_tools)

[kochetkov-ma]

API

BrewPage — https://brewpage.app

Free hosting API for HTML pages, JSON documents, key-value pairs, files, and multi-file sites. Publish anonymously; receive a short URL and an owner token for later updates. TTL-based retention (15–30 days). REST + AI-agent friendly.

Files added

• APIs/brewpage.app/1.30.3/openapi.yaml

Source of truth

• Spec: https://github.com/kochetkov-ma/brewpage-openapi/blob/main/openapi/openapi.yaml
• Rendered docs: https://kochetkov-ma.github.io/brewpage-openapi/
• Homepage: https://brewpage.app

Categories

• hosting
• developer_tools

Validation

• info.version (1.30.3) matches folder name (APIs/brewpage.app/1.30.3/).
• x-origin.url returns 200 anonymously.
• x-logo.url returns 200 anonymously.
• x-providerName set to brewpage.app.
• No conflict with existing entries.

Contact

Maintainer: @kochetkov-ma

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive OpenAPI 3.1.0 specification for the BrewPage API, which supports hosting and managing HTML, JSON, KV data, and files. The review feedback highlights several technical improvements: correcting the media type for file uploads to multipart/form-data, allowing structured data in the JSON store, and ensuring error responses use a dedicated ErrorResponse schema. Additionally, the reviewer suggests using explicit application/json media types instead of wildcards and refactoring security headers into standard securitySchemes for better maintainability and idiomatic design.

[gemini-code-assist]

The content type for file uploads should be multipart/form-data instead of application/json. This matches the operation description and is the standard way to handle binary file transfers in REST APIs.

          multipart/form-data:

[gemini-code-assist]

Using type: string for a JSON document store is restrictive. Since the API is intended to store any valid JSON, using an empty schema {} or type: object (if only objects are allowed) would be more appropriate to allow structured data to be sent and validated correctly.

              {}

[gemini-code-assist]

Error responses (403, 404) are currently referencing the success schema KvGetResponse. It is better practice to use a dedicated error schema, such as the ErrorResponse defined in your components, to ensure that clients receive consistent error structures and that auto-generated client code handles these cases correctly. This issue appears in multiple locations throughout the specification.

                $ref: '#/components/schemas/ErrorResponse'

[gemini-code-assist]

Using the wildcard media type */* for structured JSON responses is imprecise. Specifying application/json explicitly is recommended for better compatibility with client generators and to ensure correct parsing by consumers. This pattern is used across most endpoints in the specification.

            application/json:

[gemini-code-assist]

Security headers like X-Password, X-Owner-Token, and X-Admin-Password are defined as individual parameters for every operation. It is more maintainable and idiomatic to define these as securitySchemes in the components section and apply them globally or per-operation using the security field. This also allows tools to better represent the authentication requirements of the API.