Technical specification — CYBER-X

Alnomoor — table (cafeteria) ordering integration
Audience: CYBER-X technical / network / security teams
Purpose: Describe HTTP traffic you will receive from Alnomoor (scope, headers, body, source). Your internal POS behaviour is out of scope for this document.

1 Alnomoor domains, outbound scope count & whitelist IP

Public domains (reference)

Use Domain (HTTPS)
Public website / web table menu https://alnomoor.com
API (backend) — called by Alnomoor apps https://api.alnomoor.com

Outbound HTTP scope count (Alnomoor → CYBER-X)

Item Value
Number of scopes 1 — one integration surface only: POST to the single agreed full URL (CYBERX_API_URL).
HTTP methods toward your URL POST only (no GET, PUT, etc. for this feature).
Relation to the domains listed above Those domains are our public surfaces (web / apps). Calls to your server are issued only from server-side code on the Alnomoor website stack (Next.js) when an order is placed — not from browsers directly, and not from a separate outbound integration on https://api.alnomoor.com for this CYBER-X push in the current codebase (apps/website).

IPv4 for your whitelist

Item Value
IPv4 — please add to allowlist for inbound traffic from this integration 49.13.210.247
Note: Requests to your endpoint (CYBERX_API_URL) originate from egress of the Alnomoor website server (Next.js). If that egress matches 49.13.210.247, use the value above. If production egress differs (load balancer, provider change, etc.), Alnomoor hosting must confirm the new IP and CYBER-X must be notified.

2 What you provide (to connect)

Item Description
Full HTTPS URL Single receive endpoint: POST to a URL you define (scheme + host + path + optional query). Stored on our side as CYBERX_API_URL.
Authentication Bearer — secret token issued or agreed with Alnomoor, stored as CYBERX_TOKEN (never publish in public docs).

3 What you will receive on your server

Direction, method & full scope

Source IP you will see

HTTP headers (inbound to your API)

Header Expected value
Content-Type application/json
Authorization Bearer + agreed token

No additional custom headers are sent in the current implementation.

Request body

Encoding: UTF-8 — Format: JSON — One object per HTTP request.

{
  "table": "<string — table identifier>",
  "items": [
    {
      "name": "<string — item name>",
      "qty": <number — quantity, expected integer ≥ 1>
    },
    {
      "name": "<string>",
      "qty": <number>,
      "note": "<string — optional>"
    }
  ]
}
Field Meaning
tableTable identifier for this order (single string).
itemsLine items; at least one row.
items[].nameItem name.
items[].qtyQuantity as JSON number; we do not enforce a fixed digit length — JSON numeric semantics.
items[].noteOptional per line; key is omitted when empty.

Payload count & size

4 Short flow inside Alnomoor (why source IP is not the customer)

  1. The customer uses the Alnomoor website and posts to an internal site route (not directly to your URL).
  2. The website server builds the JSON above and issues POST to the URL you provided.

Therefore your firewall sees website server egress, not each customer device IP.

5 Go-live checklist

CYBER-X Alnomoor
Provide full POST URL + Bearer secret Set CYBERX_API_URL and CYBERX_TOKEN in website runtime environment
If required: allowlist including 49.13.210.247 (update if egress changes) End-to-end test after configuration
Agree any rate/size limits on your side if applicable

6 Code reference (optional)

apps/website/src/app/api/orders/route.ts — builds the payload and calls fetch to your URL.