Reference
Versioning and changelog
/api/v1 is additive only. A new field, a new operation and a new optional input are all ordinary changes; removing a field, narrowing a type or changing a status is not, and would be /api/v2.
What may change inside v1
| Change | Allowed in v1? |
|---|---|
| A new operation | Yes. |
| A new field in a response | Yes. Ignore fields you do not know. |
| A new optional field in a request | Yes. |
| A new error code | Yes. The catalogue grows whenever a service learns a new refusal, which is why an exhaustive switch over error codes needs a default. |
| A new value in a response enum | Yes, for error codes. Treat any response enum as open. |
| Removing a field from a response | No. That is /api/v2. |
| Narrowing a type or a bound in a request | No, except where the server already refused the values being removed. |
| Changing the HTTP status an operation answers | No. That is /api/v2. |
| Making an optional request field required | No. That is /api/v2. |
How a deprecation is announced
An operation on its way out carries a declared since and sunset date, and the server emits two headers on every response to it, so a client that never reads this page still finds out.
HTTP/1.1 200 OK
Deprecation: @1789516800
Sunset: Fri, 01 Jan 2027 00:00:00 GMT
Cache-Control: private, no-store| Header | Standard | Format | Example |
|---|---|---|---|
Deprecation | RFC 9745 | A Structured Fields Date item, which is an at sign followed by unix seconds. | @1789516800 |
Sunset | RFC 8594 | An HTTP-date, in the IMF-fixdate form. | Fri, 01 Jan 2027 00:00:00 GMT |
The two formats differ on purpose and it is not a typo. They come from two different specifications, written years apart, and RFC 9745 prints them side by side and says so. Parse each with what its own standard says, not with one parser for both. A date this server cannot turn into a valid value produces no header at all rather than a malformed one, because a Structured Fields parser that meets a bad value may discard the whole header section.
Deprecation says when the operation was marked. Sunset says when it stops answering. Neither header appears on an operation that is not deprecated.
The document is generated, and so is this
Every operation is declared once in the server. The HTTP route, the MCP tool, the OpenAPI document and the reference pages here are all read off that one declaration, so they cannot describe an API nobody built. A change is checked against the previous published document before it ships, and a change that a diff reports as breaking is not a version of v1.
The live document is at https://api.gogoscreen.com/api/v1/openapi.json. Generate a client from it rather than writing one by hand.
Releases
| Version | Date | What it is |
|---|---|---|
1.0.0 | 2026-09-16 | The first public version: operations over REST, every one an API key may call also an MCP tool, one error envelope, one job envelope, cursor pagination, required idempotency keys, per credential rate limits and signed webhooks. The date is the day the registry, the HTTP surface and the generated document were added to the server. It has grown additively since, as v1 allows, and today holds 71 operations, 61 of them callable with a key and as MCP tools. |
Nothing is deprecated. When something is, it appears here with its since and sunset dates, and the headers above start appearing on it the same day.