Skip to main content
Endpoints turn application logic into a governed HTTP interface. Each Endpoint owns a method and path, an optional input guard, an execution timeout, response behavior, and an optional Component target.

​
What you actually configure in the workspace

The Endpoints grid is the contract inventory: name, category, description, active state, method, path, Component, metadata, and creation time are visible before opening a definition. Select a row to configure its Details panel.

Route

Choose method and path, then make the name and category useful for operators rather than clients.

Target

Select a Component and intentionally choose Latest or a reviewed Component version.

Boundary

Configure request validation, timeout, memory, response shape, and history visibility together.

Design

Choose the HTTP contract, validation policy, and response shape.

Activate

Make a validated definition available to callers without redeploying the application.

Operate

Inspect execution statistics, logs, and traces using stable correlation IDs.

​
Endpoint lifecycle

  1. Build and test the Component that implements the request.
  2. Open Endpoints and create a definition with a unique method and path.
  3. Select a Component, or configure a static response for a lightweight endpoint.
  4. Add an inline guard or select a reusable JSON validator Component.
  5. Configure timeout, libraries, template input, and response behavior.
  6. Validate the definition and activate it.
  7. Call the Endpoint through the Endpoint Runtime URL for your environment.
  8. Use Endpoint statistics, Logs, and Trace to operate it.
Create a new Endpoint as inactive when you want to validate the contract before exposing it to callers.

​
Routing

An Endpoint is uniquely identified by its HTTP method and normalized path. Supported methods are GET, POST, PUT, PATCH, and DELETE.
Named dynamic segments are decoded and exposed to the Component as path parameters. Static paths are preferred over dynamic candidates, so /customers/current is more specific than /customers/:customerId. Paths:
  • start with /;
  • may contain letters, numbers, ., _, and - in static segments;
  • may use named parameters such as :customerId;
  • are normalized to remove repeated and trailing slashes;
  • are matched together with the HTTP method.

​
Request data

The Component receives a structured request context containing: Treat all caller-controlled fields as untrusted. Do not forward inbound headers wholesale to another system.

​
Validate input

Use one of two guard sources:
  • Inline guard for a contract that belongs only to this Endpoint.
  • JSON validator Component for a contract shared by several Endpoints or workflows.
A guard can validate body, query, headers, and parameters. You can configure the validation status code, provide a safe custom error body, or hide detailed validation errors from the caller.
Validation runs before the target Component. Keep error responses free of submitted credentials and internal validation details.

​
Configure an order command, step by step

For POST /orders/:orderId/confirm, set the route and Component first. In Options, set a short timeout because this Endpoint should create a Job and return 202, not wait for an external payment or fulfilment provider. Put stable operator-owned values in Inputs; the Component reads them through api.input(). Use a request guard for the body and path parameters, choose 202 as the success code, and enable Hide request when the payload can contain personal or financial data. The same panel offers Full result versus a selected element result, no-body responses, library selection, validation status, and request/response history controls. Choose the response contract before activation so generated OpenAPI matches what clients will receive.

​
Choose the execution target

​
Component-backed Endpoint

Use a Component-backed Endpoint for business logic, database access, integrations, and dynamic responses. Standard low-code Components can follow the latest active version or a deliberately pinned version. Hosted custom Node.js Components follow their active runtime revision. Saving source does not make an unverified revision executable: the previous active revision remains in service until the new deployment is ready and selected.

​
Static Endpoint

An Endpoint without a Component can return a configured static body and successful 2xx status. This works well for simple health, discovery, or fixed configuration responses.

​
Shape the response

For new Endpoints, use the modern response behavior:
  • return the Component result map;
  • select one named element result with popResult;
  • suppress the response body with noResult;
  • set a normal successful 2xx status;
  • deliberately return another status and body from component logic when the API contract requires it.
Legacy result envelopes remain available for existing consumers, but should not be selected for new integrations.

​
Runtime behavior

At a high level, an invocation follows this path:
Endpoint definitions are stored in the control plane. Runtime caches accelerate route matching and executable artifacts, while activation state and version selection remain authoritative. Definition changes invalidate runtime state automatically. The runtime does not automatically retry an HTTP invocation. A caller should retry only when the operation is idempotent or protected by an application idempotency key.

​
Security and access

Endpoint management and invocation are separate capabilities: Use a service account with only the roles needed by the integration. The execution principal’s current access also governs access-controlled platform operations performed during the request.

​
OpenAPI and discovery

RevoEngine can generate an OpenAPI document for all active runtime Endpoints or for one Endpoint. Use it to:
  • publish an integration contract;
  • generate a typed client;
  • import operations into API tooling;
  • compare a planned change before activation.
The generated contract describes your runtime Endpoints. The Platform API reference separately documents the control plane used to manage RevoEngine itself.

​
Production checklist

  • Validate body, query, and path parameters at the boundary.
  • Use a dedicated service account for machine callers.
  • Pin a low-code Component version when a rollout must remain immutable.
  • Set a timeout that reflects the caller’s own deadline.
  • Avoid request and response persistence for sensitive payloads when the options permit it.
  • Make retry-sensitive writes idempotent.
  • Record the Execution ID returned by your application flow and the distributed Operation ID from diagnostics.
  • Review generated OpenAPI after every contract change.

Build Components

Implement reusable business logic and manage executable versions.

Endpoint Runtime

Integrate with the synchronous execution surface.

Configuration reference

See every public route, validation, execution, and response option.

Authentication

Authenticate human and machine callers.

Observability

Diagnose an invocation across statistics, logs, and traces.
Last modified on September 5, 2026