Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.utnor.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Request format

Custom Status is accessed through a simple HTTP request with a single query parameter. 
https://status.utnor.org/?status={status_code}

​
Properties

​
status
integer
required
The HTTP status code you want the server to return.If the value is missing, invalid, or unsupported, the request will return an error response.
The status code must be between 200 and 599.

​
Example requests

Custom Status can be used from any platform or environment that can send an HTTP request. It is not tied to a specific language, framework, or tool. The examples below show a few common ways to call the tool. They are provided only as reference — any CLI, programming language, or HTTP client can be used. 
curl -i https://status.utnor.org/?status=404

​
Response behavior

When the request is valid, the server responds with the requested HTTP status code and no response body. 
HTTP/1.1 {status_code} {reason_phrase}

​
What the response includes

  • The requested HTTP status code
  • Standard HTTP headers required to deliver the response
  • Custom headers:
    • Identifies that the response comes from the UTNOR tooling, not from any CDN, proxy, or underlying infrastructure.
    • This header is always included, whether the request succeeds or fails.
    • Its primary purpose is traceability — to help clients or developers know the origin of the response.
    This header does not provide trust or guarantee correctness. It is solely informational and indicates the source of the response.
    • Indicates whether the request was processed successfully by the tool (success) or if a real system error occurred (failure).
    • success → The requested status code was executed and returned exactly as intended.
    • failure → An internal system error occurred; the client may also receive an accompanying JSON error response.
    This header is intended for distinguishing between user-simulated results and genuine system failures.
    Clients and monitoring tools should use this header to determine whether a status code reflects a user-requested output or a real backend/input error.

​
What the response does not include

  • No response body
  • No JSON payload
  • No message string
  • No metadata or diagnostics

​
HTTP Request Methods

Clients can send any custom HTTP method. The tool will respond with the requested status code exactly as for standard methods. See RFC 9110 §4.3.1 for reference.Requests using any method, standard or custom, behave the same: only the status code is returned, with no body.
GET, HEAD, POST, PUT, PATCH, DELETE
These methods are uncommon or restricted by standards for security reasons. They still work but are used less frequently. CONNECT, TRACE, LINK, UNLINK, COPY, Custom / Unknown Methods
OPTIONS is reserved for CORS preflight requests.
Requests using OPTIONS receive 204 No Content along with standard CORS headers to allow cross-origin requests.
No other methods are restricted; this is only a reserved case to ensure browser compatibility.

​
Success vs error responses

When a valid status code is provided, the server returns that code directly. Alongside the HTTP status, two additional headers help clients and tools understand the nature of the response:
  • X-Powered-By: UTNOR — clearly marks the response as originating from the UTNOR tooling, regardless of whether the request was successful or an internal error occurred. This allows clients to distinguish tool responses from other infrastructure.
  • X-UTNOR-Execution: success | failure — indicates the execution outcome. success confirms the request was processed and returned as intended; failure signals that a real system error occurred and that clients should review the accompanying JSON body details.
If the request is invalid, missing, or violates allowed rules, the server responds with an error status and a small JSON payload explaining the issue.
Detailed error formats and meanings are documented in the Common Errors section.