Gateway docsUpdated August 2026

Build and operate a controlled agent interface.

The control plane manages verified domains, approved sources, tools, client credentials, and access rules. The gateway publishes the resulting Markdown, REST, MCP, UCP, and approval-controlled actions.

Control plane

Where owners connect sources, resolve conflicts, activate tools, approve actions, and issue credentials.

Agent gateway

The machine-facing interface that returns current facts and only the actions explicitly enabled for a verified domain.

Getting started

Publish the first useful interface in five steps.

Start narrow: one verified domain, a small set of authoritative sources, and one read-only tool. Add consequential actions only after the data and approval path are tested.

Step 01

Prove control of the business domain

Add the DNS TXT record or well-known verification file generated in the control plane. A gateway is not published for an unverified domain.

domain.status → verified

Domain verification

No verified domain, no published gateway.

Verification connects the machine interface to an accountable business owner. The control plane provides either a DNS TXT challenge or a well-known verification file.

DNS TXT

_lumeo-verify.acme.example TXT lumeo-verify=…

Recommended for stable production ownership.

Well-known file

https://acme.example/.well-known/lumeo-verification

Useful where DNS changes require a separate team.

Security note

Verification proves control of the domain challenge. It does not grant permission to ingest private systems; each source still requires explicit owner configuration.

Source authority

Resolve facts before agents depend on them.

Lumeo does not treat every page or file as equally authoritative. Authority is assigned by fact type, and conflicts remain withheld until an owner resolves them.

Website

Descriptions

PDF catalog

Specifications

ERP / PIM

Price & availability

Reconcile

Canonical entity

AX-104

Price → ERP / PIM

Specification → approved PDF

Description → website

Freshness → explicit per fact

Conflict behavior

If two sources disagree and neither is authoritative for that fact, Lumeo withholds the disputed value instead of letting ingestion order decide.

API reference

Published endpoints

Select or hover over an endpoint to update the request examples in the right-hand rail. Replace the example domain and host with the values shown in your gateway console.

MethodEndpointProtocol

GET · Public when enabled

/v1/{domain}

curl --request GET \
  https://lumeoagent.com/v1/acme.example

shell

Protocol note

MCP and UCP are evolving external specifications. Confirm client compatibility and the version declared by the gateway profile before production rollout.

Gateway manifest

Discover the interfaces a domain has actually enabled.

The manifest is the canonical entry point for the domain. It reports enabled REST, Markdown, MCP, UCP, and signing capabilities alongside published catalog entities, documents, and tool schemas.

Capabilities

Only enabled interfaces are returned.

Client scope

Private actions still require a scoped credential.

Signing state

Signed-responses support is explicit, never implied.

Response validity

Integrity and freshness are separate client decisions.

Every JSON response includes an implemented `lumeo` metadata object. Equivalent validity values are returned as headers; HTTP message signatures are added only when response signing is configured for the gateway.

Signed JSON response

{
  "sku": "AX-104",
  "facts": {
    "price": 120.00,
    "currency": "EUR"
  },
  "provenance": [{
    "source": "ERP_PIM_CONNECTOR",
    "observed_at": "2026-08-12T01:30:00Z"
  }],
  "lumeo": {
    "observed_at": "2026-08-12T01:30:00Z",
    "valid_until": "2026-08-12T01:35:00Z",
    "ttl_seconds": 300,
    "content_hash": "sha256:e3b0c44298fc..."
  }
}

json

HTTP response headers

content-digest: sha-256=:47DEQpj8...:
x-lumeo-ttl: 300
x-lumeo-valid-until: 2026-08-12T01:35:00Z
signature-input: sig1=("@status" "content-digest");created=...
signature: sig1=:MEUCIQD...:

http

Client rule

Stop treating a payload as current after valid_until. A cryptographic signature proves integrity and origin; it does not make expired inventory or pricing current.

Protocols & standards

MCP for tools. UCP for commerce discovery.

Both interfaces are generated from the same canonical domain model, so the business does not maintain separate copies of product facts or action rules.

Model Context Protocol

Agents can initialize a session, list tools, read approved resources, and call published tools. Tool schemas, client scope, and approval rules remain controlled in Lumeo.

Open MCP example ↑

Universal Commerce Protocol

The well-known profile advertises commerce capabilities, tool endpoints, polling behavior, signing keys, and the binding-terms fields supported by the gateway.

Open UCP example ↑

Asynchronous workflow

RFQs become durable approval-controlled actions.

`prepare_rfq` validates item structure and MOQ, creates an estimative draft, and returns an action identifier. The buyer agent polls while the responsible sales team decides whether the final quote can become binding.

Agent prepares RFQ

POST prepare_rfq with items, quantities, destination, and target date.

Gateway returns 202

The response includes action_id, poll_url, and an estimative draft.

Sales reviews terms

A person may adjust price, freight, validity, discount, and quote type.

Agent receives the result

Polling returns the final status and signed quote payload when approved.

Optional delivery alert

Email or webhook tells the responsible team that a decision is waiting.

→

The queue remains authoritative

A missed notification never changes the durable action state or approval boundary.

quote_type

binding or estimative_only

valid_until

ISO-8601 expiry

currency

Uppercase settlement currency

moq_enforced

True when quantities passed

Binding boundary

Approval of a binding quote is rejected when complete pricing or an explicit total is unavailable. The signed result remains subject to its quantities, terms, and valid_until.

Tool control

Publish capabilities according to operational risk.

A tool is a contract: input schema, output shape, required client scope, execution method, approval rule, and pricing policy should be understood before activation.

Risk class	Examples	Approval	Default behavior
Read / discovery	search_catalog · get_spec	Automatic when scoped	Grounded execution
Draft action	prepare_rfq · check_lead_time	Async queue	Returns action ID and draft
Financial / write	submit_order · update_pricing	Owner approval required	Paused before execution

Recommended default

Allow narrow read operations to execute automatically only when scoped and grounded. Keep financial, write, and administrative operations paused until their integration and rollback behavior have been independently tested.

Deployment

Production readiness checklist

Use this browser-local checklist during implementation. Completion indicates that the listed decisions were reviewed; it is not a certification or substitute for your organization’s security process.

Deployment progress

Saved only in this browser.

0/7

InfrastructurePersistent object storage and KMS are configured for the deployment.SecuritySigning keys remain outside source control and credential encryption is configured.Payments & meteringWebhook signatures are verified and the x402 facilitator is reviewed when enabled.Source controlSource conflicts are resolved; response TTLs and quote validity rules are reviewed.Commercial rulesMOQ enforcement and rejection of incomplete binding quotes are tested.WorkflowsRFQ polling, approval expiry, and email or webhook delivery are tested.OperationsAn owner is assigned for client credential rotation and incident response.