Hype Custom Integration -- API Reference

Adapter key: hype-custom (HC) Postman docs: https://documenter.getpostman.com/view/52109283/2sBXc8oNnL

---

Table of Contents

1. Overview
2. Architecture
3. Authentication
4. Base URLs & Rate Limits
5. Error Handling
6. Task System
7. Entity Reference
   • Items
   • Categories
   • Supplements
   • Saloons
   • Tables
   • Order Requests
   • Order Delivery Channels
   • Order Payment Types
   • Order Request Status
8. Webhook Endpoints
9. Integration Management
10. Queue Management
11. Integration & Pipeline Statuses
12. Initial Sync Pipeline
13. Ongoing Synchronization
14. Quick Reference

---

1. Overview

Hype Custom is a bidirectional integration adapter within the Hype Exchange Service (HES) -- a cloud middleware that enables data synchronization between Hype POS systems (on-premise restaurant software) and third-party platforms.

The hype-custom adapter allows any external platform to:

• Receive categories, supplements, saloons, tables, and menu items (articles) from the Hype POS
• Send order requests (online orders) into the Hype POS
• Synchronize delivery channels, payment types, and order statuses between platforms
• Manage order lifecycle (create, update status, track delivery)

What is Hype?

Hype Software is a hospitality ERP system for bars, restaurants, and cafes. Your platform integrates with it through HES to receive catalog data, submit orders, and receive order status updates.

Key Concepts

Concept	Description
HES	Hype Exchange Service -- the cloud middleware at es.hype-software.com that brokers all integration communication
Adapter	A platform-specific plugin within HES. hype-custom is the adapter for generic third-party platforms
Integration	A configured connection between a Hype POS account and an external platform account
Task	A unit of work created by HES for a platform to process (create/update/fetch an entity)
Pipeline	An orchestrated sequence of sync steps during initial integration setup
Entity Value Mapping	Internal HES links between entity IDs across platforms (e.g., "Item #5 on Hype = Product #123 on your platform")
Account	Each side of an integration -- one Hype Server account and one external platform account

---

2. Architecture

How Hype Custom Fits Into HES

Your platform -> HES: fetch synchronization tasks (GET)
Your platform -> HES: submit task results (PUT)
Your platform -> HES: submit orders and changes (POST/PUT webhook)
HES -> Your platform: pending tasks, request responses, integration status

Communication Patterns

There are two communication patterns used by the hype-custom adapter:

1. Task Polling (HES -> Your Platform)

When Hype POS pushes data to HES (e.g., a new menu item), HES creates tasks for your platform. Your platform periodically polls for these tasks, processes them, and reports results.

HES makes catalog changes available as tasks for your platform
Your Platform  -->  GET /tasks/hype-custom/items  -->  HES returns pending tasks
Your Platform processes tasks (creates/updates records)
Your Platform  -->  PUT /tasks/hype-custom/items  -->  Reports results to HES

2. Webhook Push (Your Platform -> HES)

When your platform needs to send data to Hype (e.g., a new online order), it pushes directly to HES via webhook endpoints.

Your Platform  -->  POST /webhook/hype-custom/orderRequests  -->  HES
  HES accepts the request with 204 and handles delivery asynchronously
  Confirm the order appears in Hype; 204 alone does not confirm delivery

---

3. Authentication

All API requests require a Bearer Token in the Authorization header.

Authorization: Bearer <your_api_token>

Obtaining an API Token

An API token is provisioned when an integration is created between your platform and a Hype POS client. Contact the Hype support center to set up an integration. You will receive an api_token tied to your platform's account within HES.

Authentication Error

If the token is missing or invalid, the API returns:

HTTP/1.1 401 Unauthorized

Required Headers

All requests should include:

Content-Type: application/json
Accept: application/json
Authorization: Bearer <your_api_token>

---

4. Base URLs & Rate Limits

Environments

Environment	Base URL
Development	https://es.dev.hype-software.com
Production	https://es.hype-software.com

All communication is HTTPS only. HTTP requests are redirected with 301 to their HTTPS equivalent.

Rate Limits

Limits apply per API token and depend on the endpoint group:

Endpoints	Limit
/tasks/hype-custom/* and /webhook/hype-custom/*	1000 requests per minute
/api/hype-custom/* (integrations and queue jobs)	60 requests per minute

Exceeding a limit returns 429 Too Many Requests.

Response Header	Description
X-RateLimit-Limit	Maximum requests allowed per minute
X-RateLimit-Remaining	Requests remaining in the current window

These headers are sent on requests within the limit. A 429 response does not include Retry-After or X-RateLimit-Reset, so wait before retrying (the window is one minute), for example with exponential backoff.

---

5. Error Handling

Authentication, routing, rate-limit, and unexpected server errors return the HTTP status code with this JSON body:

{
  "error": 1,
  "message": "Error description text"
}

Status Code	Meaning
401	Unauthorized -- missing or invalid Bearer token
404	Unknown task entity in /tasks/hype-custom/{entity}, unknown entity_task_id, or unknown integration
429	Too Many Requests -- rate limit exceeded
500	Internal server error. Also returned for queue-job requests on an integration outside your account and for a task result without entity_task_id

HES does not validate request bodies synchronously, so these endpoints never return 422:

• Webhooks (/webhook/hype-custom/{entity}) accept any JSON body with 204 No Content and process it asynchronously. A malformed payload fails later; check the integration's queue jobs for the error.
• A webhook for an unsupported entity name does not return 404: POST returns 500, and the other methods return 200 with {"error": "Resource can't be found"}. Check the entity name in the URL whenever a webhook returns anything other than 204.
• A task result without status is recorded as failed.

---

6. Task System

The task system is the core mechanism for synchronizing data from Hype POS to your platform. HES creates tasks that your platform must fetch, process, and report back on.

How It Works

1. HES creates tasks when entities change on the Hype POS side (or during initial sync)
2. Your platform polls for pending tasks via GET /tasks/hype-custom/{entity}
3. Your platform processes each task (creates, updates, or fetches records in your system)
4. Your platform reports results via PUT /tasks/hype-custom/{entity}

Task Object Structure

Every task returned by a GET request has this structure:

{
  "id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
  "request": { ... },
  "status": 0,
  "meta": {
    "source_account": {
      "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
      "name": "Local",
      "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
      "platform_name": "Hype Server",
      "platform_key": "hype-server"
    }
  },
  "type": "POST"
}

Field	Type	Description
id	UUID string	Task identifier -- needed when reporting the result back
request	object/array	The entity data to process. For GET tasks it carries the integration settings stored for your account, or [] when there are none; you do not need to act on it.
status	integer	Always 0 (new/unprocessed) when fetched
meta	object	source_account describes the Hype Server account the change came from: id, name, platform_id, platform_name, platform_key
type	string	The operation to perform: GET = send all records of this type from your system, POST = create a new record, PUT = update an existing record

Task Type Semantics

Type	Meaning	Your Action
GET	HES needs all records of this entity type from your platform	Return all records in your response
POST	A new entity was created in Hype -- create it in your system	Create the record, return it with your platform's ID
PUT	An existing entity was updated in Hype -- update it in your system	Update the record, return the updated version

HES does not currently send DELETE tasks. When a mapped record is deleted in Hype, you receive a PUT task for it with its fields reset to empty or zero values (for example "name": ""). Check for this case before applying a PUT, and delete the record instead if you mirror deletions.

Reporting Task Results

After processing tasks, report results with a PUT request. The body is an array of task results:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": { ... },
    "status": 201
  }
]

Field	Type	Description
entity_task_id	UUID string	The id from the original task
response	object/array	The result of processing. Successful non-GET tasks should include id -- your platform's ID for the entity. Successful GET tasks should return an array of all records for that entity type.
status	integer	HTTP status code indicating result: 200 = updated, 201 = created, 4xx/5xx = error

A successful PUT returns 204 No Content.

For successful non-GET tasks, return your platform's id whenever your platform created or matched a real entity. HES uses that id to build entity mappings for later synchronization.

For successful GET tasks, return a JSON array in response. Each item should use the same schema as that entity and include your platform's stable id. HES uses these arrays during initial sync to collect your order statuses, delivery channels, and payment types for manual pairing in the Hype Server back-office UI after activation. Return an empty array only when your platform has no records for that entity.

Saloons/tables exception: If your integration does not model venue floor plans and does not need saloon/table mappings, you may acknowledge successful saloon or table tasks with an empty response object:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": {},
    "status": 200
  }
]

This advances the integration but does not create a saloon/table ID mapping. If you use this option, do not include tableId when creating order requests for Hype Server because HES will not be able to translate that table reference.

---

7. Entity Reference

7.1 Items

Items represent menu articles (sellable items) in the Hype POS -- dishes, drinks, etc.

Schema

Field	Type	Required	Description
id	string/integer	Yes (on PUT/response)	Your platform's unique identifier for this item
name	string	Yes	Item name
categoryId	string/integer	Yes	Category ID mapped to your platform's category entity
price	number	Yes	Item price
preparationTime	integer	No	Preparation time in minutes. Tasks send 0 when Hype has no value.
barCode	string	No	Barcode value
modifiers	array	No	List of modifier IDs (not used yet)
supplements	array	No	Always empty ([]) in PUT tasks and absent from POST tasks. Use the standalone supplements entity.
quantity	integer	No	Always 1. It is not stock or availability.
active	boolean	Yes	Whether the item is active/visible

Note: Item tasks do not carry supplement data. Supplements, their mappings, and order-item supplement references come from the standalone supplements entity.

Endpoints

Method	URL	Description
GET	/tasks/hype-custom/items	Fetch pending item tasks
PUT	/tasks/hype-custom/items	Report item task results

Example: Fetch Item Tasks

Request:

GET /tasks/hype-custom/items
Authorization: Bearer <token>
Content-Type: application/json
Accept: application/json

Response: 200 OK

[
  {
    "id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "request": {
      "name": "Маргарита 20",
      "categoryId": 31,
      "price": 4.33,
      "preparationTime": 20,
      "barCode": "812345679",
      "modifiers": [],
      "quantity": 1,
      "active": true
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "POST"
  },
  {
    "id": "9a101f76-f1c8-47c2-a19f-439150bb58ab",
    "request": {
      "id": "87001",
      "name": "Coca Cola",
      "categoryId": 31,
      "price": 2.5,
      "preparationTime": 0,
      "barCode": "712345689",
      "modifiers": [],
      "supplements": [],
      "quantity": 1,
      "active": true
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "PUT"
  }
]

Example: Report Item Task Results

Request:

PUT /tasks/hype-custom/items
Authorization: Bearer <token>
Content-Type: application/json
Accept: application/json

Body:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": {
      "id": "87008",
      "name": "Маргарита 20",
      "categoryId": 31,
      "price": 4.33,
      "preparationTime": 20,
      "barCode": "812345679",
      "modifiers": [],
      "supplements": [],
      "quantity": 1,
      "active": true
    },
    "status": 201
  },
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-439150bb58ab",
    "response": {
      "id": "87001",
      "name": "Coca Cola",
      "categoryId": 31,
      "price": 2.5,
      "preparationTime": 0,
      "barCode": "712345689",
      "modifiers": [],
      "supplements": [],
      "quantity": 1,
      "active": true
    },
    "status": 200
  }
]

Response: 204 No Content

---

7.2 Categories

Categories group menu items. Hype uses a two-level hierarchy: main categories and menu categories.

Schema

Field	Type	Required	Description
id	string/integer	Yes (on PUT/response)	Your platform's unique identifier
name	string	Yes	Category name
order	integer	Yes	Sort order

Endpoints

Method	URL	Description
GET	/tasks/hype-custom/categories	Fetch pending category tasks
PUT	/tasks/hype-custom/categories	Report category task results

Example: Fetch Category Tasks

Request:

GET /tasks/hype-custom/categories
Authorization: Bearer <token>

Response: 200 OK

[
  {
    "id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "request": {
      "name": "Сандвичи",
      "order": 1
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "POST"
  },
  {
    "id": "9a101f76-f1c8-47c2-a19f-439150bb58ab",
    "request": {
      "name": "Пици",
      "order": 2
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "POST"
  },
  {
    "id": "9a101f76-f1c8-47c2-a19f-489150bb62b1",
    "request": {
      "id": 234,
      "name": "Бира",
      "order": 3
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "PUT"
  }
]

Example: Report Category Task Results

Request:

PUT /tasks/hype-custom/categories
Authorization: Bearer <token>

Body:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": {
      "id": "3011",
      "name": "Сандвичи",
      "order": 1
    },
    "status": 201
  },
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-439150bb58ab",
    "response": {
      "id": "135",
      "name": "Пици",
      "order": 2
    },
    "status": 201
  }
]

Response: 204 No Content

---

7.3 Supplements

Each supplement record links an add-on to one item, with its price for that item. Supplements reach your platform through their own tasks; item tasks don't carry them. Order payloads reference them by id in orderDetails.items[].supplements[].

Supplement tasks appear during initial sync and whenever a supplement is added or changed in Hype.

Schema

Field	Type	Required	Description
id	string/integer	Yes (on PUT/response)	Your platform's unique menu-scoped supplement identifier
articleId	string/integer	Yes	Your platform's item identifier for the related article
price	number	Yes	Supplement sale price for this item
name	string	No	Supplement name. Tasks always include it; it matches supplement.name.
supplement	object	Yes	Nested supplement details

Nested: supplement

Field	Type	Description
name	string	Supplement name

Endpoints

Method	URL	Description
GET	/tasks/hype-custom/supplements	Fetch pending supplement tasks
PUT	/tasks/hype-custom/supplements	Report supplement task results

Example: Fetch Supplement Tasks

Response: 200 OK

[
  {
    "id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "request": {
      "articleId": "item-101",
      "price": 2.5,
      "name": "Extra cheese",
      "supplement": {
        "name": "Extra cheese"
      }
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "POST"
  }
]

Example: Report Supplement Task Results

Body:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": {
      "id": "supplement-301",
      "articleId": "item-101",
      "price": 2.5,
      "supplement": {
        "name": "Extra cheese"
      }
    },
    "status": 201
  }
]

Response: 204 No Content

---

7.4 Saloons

Saloons represent venue rooms or zones in the Hype POS floor plan, such as Main Hall, Garden, or Bar Area.

Saloon tasks appear during initial sync and whenever a saloon is added or changed in Hype.

Schema

Field	Type	Required	Description
id	string/integer	Usually (on PUT/response)	Your platform's unique saloon identifier
name	string	Yes	Saloon name
width	integer	Yes	Floor plan width
height	integer	Yes	Floor plan height
order	integer	Yes	Sort order

Endpoints

Method	URL	Description
GET	/tasks/hype-custom/saloons	Fetch pending saloon tasks
PUT	/tasks/hype-custom/saloons	Report saloon task results

Example: Fetch Saloon Tasks

Response: 200 OK

[
  {
    "id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "request": {
      "name": "Main Hall",
      "width": 2400,
      "height": 1400,
      "order": 1
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "POST"
  }
]

Example: Report Saloon Task Results

Body:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": {
      "id": "saloon-11",
      "name": "Main Hall",
      "width": 2400,
      "height": 1400,
      "order": 1
    },
    "status": 201
  }
]

Response: 204 No Content

If your platform does not store saloons, you can acknowledge a successful saloon task with status: 200 and response: {}. This lets the initial sync continue without creating a saloon mapping.

---

7.5 Tables

Tables represent non-virtual physical tables in the venue layout. They depend on saloons, so saloon mappings must exist before table tasks can be fully processed.

Table tasks appear during initial sync and whenever a table is added or changed in Hype.

Schema

Field	Type	Required	Description
id	string/integer	Usually (on PUT/response)	Your platform's unique table identifier
name	string	Yes	Table name
saloonId	string/integer	Yes	Your platform's saloon ID, already translated by HES, or 0 if you acknowledged the saloon with {}
x	integer	Yes	X coordinate in the saloon layout
y	integer	Yes	Y coordinate in the saloon layout
width	integer	Yes	Table width in the layout
height	integer	Yes	Table height in the layout

Notes:

• Only non-virtual tables are synchronized.
• Table payloads include position and dimensions, but do not include styling or settings data.
• If your platform does not store tables, you can acknowledge successful table tasks with status: 200 and response: {}. This advances initial sync without creating table mappings; in that case, do not send tableId in order request webhooks.

Endpoints

Method	URL	Description
GET	/tasks/hype-custom/tables	Fetch pending table tasks
PUT	/tasks/hype-custom/tables	Report table task results

Example: Fetch Table Tasks

Response: 200 OK

[
  {
    "id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "request": {
      "name": "T12",
      "saloonId": "saloon-11",
      "x": 320,
      "y": 180,
      "width": 96,
      "height": 96
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "POST"
  }
]

Example: Report Table Task Results

Body:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": {
      "id": "table-88",
      "name": "T12",
      "saloonId": "saloon-11",
      "x": 320,
      "y": 180,
      "width": 96,
      "height": 96
    },
    "status": 201
  }
]

Response: 204 No Content

---

7.6 Order Requests

Order requests represent incoming orders from your platform to the Hype POS. This is the most complex entity, containing nested objects for payment, delivery, client details, and order items.

Schema

Field	Type	Required	Description
id	string/integer	Yes	Your platform's unique order ID
tableId	string/integer	No	Your platform's table identifier. If provided, it must already be mapped through the standalone tables sync.
discount	number	No	Total discount amount
tip	number	No	Gross tip amount. Sent to Hype Server as an order-level surcharge. Missing tip is treated as 0.
paymentTypes	array	Yes	Payment methods used (see below)
orderComment	string	No	General comment for the order
deliveryChannel	object	Yes	Delivery method details (see below). Its id must be mapped during setup. Without deliveryChannel, HES still returns 204 but cannot deliver the order to Hype.
status	object	Yes	Current order status (see below)
clientDetails	object	No	Customer information (see below)
orderDetails	object	Yes	Order line items (see below)
total	number	Yes	Total order amount (after discounts, including delivery and tip)
subTotal	number	Yes	Subtotal before discounts/delivery

Nested: paymentTypes[]

Field	Type	Description
id	string/integer	Payment type ID (mapped via initial sync)
name	string	Payment type name
amount	number	Amount paid with this method
status	string	Payment status. Use "completed" when the amount is already collected and "pending" when the method is selected but unpaid. Any other value is treated as unpaid by Hype Server.

Hype Server applies paymentTypes[].status when the order is attached to a table account (accepted). Until then, while the order is still new, an update webhook replaces paymentTypes, so payment changes sent before acceptance take effect. Payment-status changes sent after the order is attached are ignored.

Nested: deliveryChannel

Field	Type	Description
id	string/integer	Delivery channel ID (mapped via initial sync)
name	string	Channel name
deliveryPrice	number	Delivery fee

Nested: status

Field	Type	Description
id	string/integer	Status ID (mapped via initial sync)
name	string	Status name (e.g., "New", "Accepted")

Nested: clientDetails

Field	Type	Description
firstName	string	Customer first name
lastName	string	Customer last name
phone	string	Phone number
city	string	City
postCode	string	Postal code
address	string	Street address
formatted	string	Full formatted address string

Nested: orderDetails

Field	Type	Description
items	array	Array of order line items (see below)

Note: Use orderDetails.items for both create and update requests.

Nested: orderDetails.items[]

Field	Type	Description
id	string/integer	Item/article ID (mapped via initial sync from items entity)
name	string	Item name
modifierIds	array	Array of modifier IDs (not supported yet)
supplements	array	Optional supplement objects with required id, optional per-unit price, and optional quantity (defaults to 1). Supplement IDs are mapped through the menu-scoped supplements sync.
comment	string	Item-specific comment
quantity	integer	Quantity ordered
orderPrice	number	Price per unit at time of order

Nested: orderDetails.items[].supplements[]

Field	Type	Description
id	string/integer	Your platform's supplement identifier
price	number	Optional per-unit supplement price for a single supplement unit on this order item
quantity	integer	Optional supplement quantity for this order item. Defaults to 1 when omitted.

Note: supplements[].price is a unit price, not a line total. If you need the total supplement amount for the order item, calculate price * quantity.

Endpoints

Task endpoints (for receiving order request updates from Hype):

Method	URL	Description
GET	/tasks/hype-custom/orderRequests	Fetch pending order request tasks
PUT	/tasks/hype-custom/orderRequests	Report order request task results

Webhook endpoints (for sending orders to Hype):

Method	URL	Description
POST	/webhook/hype-custom/orderRequests	Create a new order request
PUT	/webhook/hype-custom/orderRequests	Update an existing order request

Example: Create Order Request (Webhook)

Request:

POST /webhook/hype-custom/orderRequests
Authorization: Bearer <token>
Content-Type: application/json

Body:

{
  "id": 1,
  "tableId": 42,
  "discount": 3.45,
  "tip": 2.5,
  "paymentTypes": [
    {
      "id": 1,
      "name": "Stripe",
      "amount": 12.75,
      "status": "completed"
    }
  ],
  "orderComment": "Коментар към поръчката",
  "deliveryChannel": {
    "id": 1,
    "name": "За плажа",
    "deliveryPrice": 2.5
  },
  "status": {
    "id": 1,
    "name": "Нова"
  },
  "clientDetails": {
    "firstName": "Иван",
    "lastName": "Иванов",
    "phone": "+12345",
    "city": "Бургас",
    "postCode": "8000",
    "address": "кв. Възраждане, 111",
    "formatted": "Бургас, 8000, кв. Възраждане, 111"
  },
  "orderDetails": {
    "items": [
      {
        "id": 255653,
        "name": "Маргарита 20",
        "modifierIds": [],
        "supplements": [
          {
            "id": 3,
            "price": 2.0,
            "quantity": 1
          }
        ],
        "comment": "Да няма нищо зелено, като рукола зелени маслини или чушки",
        "quantity": 2,
        "orderPrice": 4.33
      }
    ]
  },
  "total": 12.75,
  "subTotal": 8.67
}

Response: 204 No Content

Example: Update Order Request (Webhook)

Use this to replace the current snapshot of a pending order request. Send the same payload shape as create when the order is still new and not yet attached/accepted in Hype.

Request:

PUT /webhook/hype-custom/orderRequests
Authorization: Bearer <token>
Content-Type: application/json

Body:

{
  "id": 1,
  "tableId": 42,
  "discount": 3.45,
  "tip": 2.5,
  "paymentTypes": [
    {
      "id": 1,
      "name": "Stripe",
      "amount": 12.75,
      "status": "completed"
    }
  ],
  "orderComment": "Коментар към поръчката",
  "deliveryChannel": {
    "id": 1,
    "name": "За плажа",
    "deliveryPrice": 2.5
  },
  "status": {
    "id": 2,
    "name": "Приета"
  },
  "clientDetails": {
    "firstName": "Иван",
    "lastName": "Иванов",
    "phone": "+12345",
    "city": "Бургас",
    "postCode": "8000",
    "address": "кв. Възраждане, 118",
    "formatted": "Бургас, 8000, кв. Възраждане, 118"
  },
  "orderDetails": {
    "items": [
      {
        "id": 255653,
        "name": "Маргарита 20",
        "modifierIds": [],
        "supplements": [
          {
            "id": 3,
            "price": 2.0,
            "quantity": 1
          }
        ],
        "comment": "Да няма нищо зелено, като рукола, зелени маслини или чушки",
        "quantity": 2,
        "orderPrice": 4.33
      }
    ]
  },
  "total": 12.75,
  "subTotal": 8.67
}

Response: 204 No Content

Notes:

• PUT /webhook/hype-custom/orderRequests accepts the same fields as the create webhook (tableId, paymentTypes, deliveryChannel, clientDetails, orderDetails.items, tip, totals, and status).
• In the current Hype Server flow, those full-field updates are applied while the order request is still new and not attached to a table account.
• After the order is attached/accepted in Hype, PUT processing becomes status-driven. In practice, status is the field you should rely on for later updates.

Example: Fetch Order Request Tasks (from Hype)

When the Hype POS updates an order status (e.g., changes it to "Accepted"), HES creates a PUT task for your platform.

Request:

GET /tasks/hype-custom/orderRequests
Authorization: Bearer <token>

Response: 200 OK

[
  {
    "id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "request": {
      "id": 1,
      "status": {
        "id": 2,
        "name": "Приета"
      }
    },
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "PUT"
  }
]

Notes:

• Hype refreshes the mapped order status. Other fields may be retained from earlier stored order data; they are not a fresh order snapshot. The example shows only the id and status your handler needs.
• Use the outer status field in the report payload for your processing result (for example 200 on success).

Example: Report Order Request Task Results

Request:

PUT /tasks/hype-custom/orderRequests
Authorization: Bearer <token>

Body:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": {
      "id": 1,
      "status": {
        "id": 2,
        "name": "Приета"
      }
    },
    "status": 200
  }
]

Response: 204 No Content

---

7.7 Order Delivery Channels

Delivery channels represent how orders are fulfilled (e.g., "Dine-in", "Takeaway", "Beach delivery"). These are synchronized during initial setup only so HES can map delivery method IDs between platforms.

⚠️ Those are not automatically mapped. Once the integration is active, manual mapping for delivery channels, payment types, and order status must be done in the POS platform.

Schema

Field	Type	Required	Description
id	string/integer	Yes	Your platform's delivery channel ID
name	string	Yes	Channel name
deliveryPrice	number	No	Default delivery fee

Endpoints

Task endpoints:

Method	URL	Description
GET	/tasks/hype-custom/orderDeliveryChannels	Fetch pending delivery channel tasks
PUT	/tasks/hype-custom/orderDeliveryChannels	Report delivery channel task results

Webhook endpoints:

Method	URL	Description
POST	/webhook/hype-custom/orderDeliveryChannels	Create a delivery channel
PUT	/webhook/hype-custom/orderDeliveryChannels	Update a delivery channel

Example: Fetch Delivery Channel Tasks

Response: 200 OK

[
  {
    "id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "request": [],
    "status": 0,
    "meta": {
      "source_account": {
        "id": "a0fa1fe5-feda-4753-9f23-691343e3828c",
        "name": "Local",
        "platform_id": "4d410b0e-ee37-497e-8362-478a383d68ee",
        "platform_name": "Hype Server",
        "platform_key": "hype-server"
      }
    },
    "type": "GET"
  }
]

A GET type task means HES is requesting all delivery channels from your platform.

Example: Report Delivery Channel Task Results

Body:

[
  {
    "entity_task_id": "9a101f76-f1c8-47c2-a19f-259150bb62e0",
    "response": [
      {
        "id": 1,
        "name": "Takeaway"
      },
      {
        "id": 2,
        "name": "Delivery"
      }
    ],
    "status": 200
  }
]

Response: 204 No Content

Example: Create Delivery Channel (Webhook)

Request:

POST /webhook/hype-custom/orderDeliveryChannels
Authorization: Bearer <token>
Content-Type: application/json

Body:

{
  "id": 1,
  "name": "За плажа",
  "deliveryPrice": 2.5
}

Response: 204 No Content

Example: Update Delivery Channel (Webhook)

Body:

{
  "id": 1,
  "name": "За плажа",
  "deliveryPrice": 2.2
}

Response: 204 No Content

---

7.8 Order Payment Types

Payment types represent how customers pay (e.g., "Stripe", "Cash", "PayPal"). Synchronized during initial setup only for ID mapping.

Schema

Field	Type	Required	Description
id	string/integer	Yes	Your platform's payment type ID
name	string	Yes	Payment type name

Endpoints

Task endpoints:

Method	URL	Description
GET	/tasks/hype-custom/orderPaymentTypes	Fetch pending payment type tasks
PUT	/tasks/hype-custom/orderPaymentTypes	Report payment type task results

Webhook endpoints:

Method	URL	Description
POST	/webhook/hype-custom/orderPaymentTypes	Create a payment type
PUT	/webhook/hype-custom/orderPaymentTypes	Update a payment type

Example: Create Payment Type (Webhook)

Body:

{
  "id": 1,
  "name": "Stripe"
}

Response: 204 No Content

Example: Update Payment Type (Webhook)

Body:

{
  "id": 1,
  "name": "Stripe 2"
}

Response: 204 No Content

---

7.9 Order Request Status

Order statuses define the lifecycle of an order (e.g., "New", "Accepted", "Preparing", "Delivered"). Synchronized during initial setup only for ID mapping.

Schema

Field	Type	Required	Description
id	string/integer	Yes	Your platform's status ID
name	string	Yes	Status name

Endpoints

Task endpoints:

Method	URL	Description
GET	/tasks/hype-custom/orderRequestStatus	Fetch pending status type tasks
PUT	/tasks/hype-custom/orderRequestStatus	Report status type task results

Webhook endpoints:

Method	URL	Description
POST	/webhook/hype-custom/orderRequestStatus	Create a status type
PUT	/webhook/hype-custom/orderRequestStatus	Update a status type

Example: Create Order Request Status (Webhook)

Body:

{
  "id": 1,
  "name": "Нова"
}

Response: 204 No Content

Example: Update Order Request Status (Webhook)

Body:

{
  "id": 1,
  "name": "Изчакваща"
}

Response: 204 No Content

---

8. Webhook Endpoints

All webhook endpoints use the same URL pattern with the entity name as a path parameter:

POST /webhook/hype-custom/:entity    -- Create an entity
PUT  /webhook/hype-custom/:entity    -- Update an entity

:entity Value	Entity Type
orderRequests	Order Requests
orderDeliveryChannels	Delivery Channels
orderPaymentTypes	Payment Types
orderRequestStatus	Order Request Statuses

Notes:

• All webhook endpoints return 204 No Content on success
• Items, Categories, Supplements, Saloons, and Tables flow from Hype to your platform via the task system. Do not send them through hype-custom webhooks: the webhook endpoint accepts items, categories, and supplements payloads with 204, but HES does not forward them to Hype
• Order Requests flow bidirectionally: your platform pushes via webhooks, and Hype pushes updates via tasks
• Delivery Channels, Payment Types, and Statuses are pushed via webhooks primarily during initial synchronization

---

9. Integration Management

These endpoints let you inspect the state of your integrations with Hype POS clients.

Get All Integrations

GET /api/hype-custom/integrations
Authorization: Bearer <token>

Response:

[
  {
    "id": "9b57a2e7-48e3-4173-9bcd-11a831a6f111",
    "status": "syncing"
  }
]

Get Integration Details

The default response contains id and status. Request include=accountOne,pipeline for the expanded example below, or include=pipeline for synchronization progress. If no pipeline exists, pipeline is omitted.

GET /api/hype-custom/integrations/:integrationId?include=accountOne,pipeline
Authorization: Bearer <token>

Response:

{
  "id": "9b57a2e7-48e3-4173-9bcd-11a831a6f111",
  "status": "syncing",
  "accountOne": {
    "id": "9a583928-13d9-4a0f-bb7f-c02b847a927c",
    "name": "demo.hype-software.com",
    "status": "active",
    "api_token": "9a583928-0e98-418a-940c-6650faf12163",
    "foreign_account_id": "157",
    "client_id": 157,
    "settings": [],
    "platform": {
      "id": "4d410b0e-ee37-497e-8362-478a383d68ee",
      "name": "Hype Server",
      "key": "hype-server",
      "prefix": "HS"
    }
  },
  "pipeline": {
    "id": "9b57a2e7-dd9b-428f-be5a-3173b77aebad",
    "status": "processing",
    "progress": {
      "step": 6,
      "from": 11,
      "task_id": "9b57a3a2-6cf6-4c06-9037-cea260069b6f"
    },
    "message": null
  }
}

Integration Details Fields

Field	Description
id	Integration UUID
status	Current integration status -- see Integration & Pipeline Statuses
accountOne	The Hype Server account connected to this integration
accountOne.platform	Platform metadata (always "Hype Server" for this side)
pipeline	Latest pipeline, requested with include=pipeline; omitted if none exists
pipeline.progress.step	Current sync step number (1-indexed). Once the pipeline is synced, it stays at the last step's index, which is from - 1.
pipeline.progress.from	Total number of sync steps (11 for a standard hype-custom integration)
pipeline.progress.task_id	UUID of the EntityTask currently being processed in this step
pipeline.status	Pipeline status: "pending", "processing", "synced", "failed", "stopped"
pipeline.message	Error message text (populated on failure, null otherwise)

---

10. Queue Management

Queue jobs are the internal processing units within HES that create sync tasks. When entity dependencies are not yet synchronized, jobs can fail or be paused.

Get Queue Jobs

GET /api/hype-custom/integrations/:integrationId/queue-jobs
Authorization: Bearer <token>

Response:

[
  {
    "id": "1f6cc4e9-222f-4ee1-95fd-517e9b28dde8",
    "entity": "CategoryEntity",
    "request_method": "POST",
    "payload": {
      "id": 53,
      "name": "TEST 4",
      "color": "#674AEF",
      "order": 9007199254740991,
      "createdAt": "2024-04-15T12:15:37.013Z",
      "updatedAt": "2024-04-15T12:15:57.000Z",
      "mainCategoryId": null
    },
    "source": {
      "id": "9a583928-13d9-4a0f-bb7f-c02b847a927c",
      "name": "demo.hype-software.com"
    },
    "status": "failed",
    "error_msg": "The entity with name TEST 4, which the platform is attempting to update, has not yet been fully synchronized between the two platforms."
  },
  {
    "id": "5de7fd5e-9fb0-4e19-9c01-8763a90094a3",
    "entity": "OrderRequestStatusEntity",
    "request_method": "POST",
    "payload": {
      "id": 1,
      "translationKey": "NEW",
      "src_status": {}
    },
    "source": {
      "id": "9a583928-13d9-4a0f-bb7f-c02b847a927c",
      "name": "hype-fe.stage.scalewest.com"
    },
    "status": "pending",
    "error_msg": null
  }
]

Queue Job Fields

Field	Type	Description
id	UUID	Queue job identifier
entity	string	Entity class name (e.g., "CategoryEntity", "OrderRequestStatusEntity")
request_method	string	HTTP method from the originating webhook (POST, PUT, DELETE)
payload	object	Raw entity data from the source platform
source	object	The source account that sent this data
status	string	"failed" or "pending"
error_msg	string/null	Error context if status is "failed"

Common Failure Reason

Jobs fail when they reference entities that haven't been synchronized yet. For example, an order request referencing an item that doesn't have an entity value mapping yet. HES pauses the queue and retries when the missing entity is synchronized.

Delete Queue Job(s)

DELETE /api/hype-custom/integrations/:integrationId/queue-jobs/:jobId
Authorization: Bearer <token>

Parameter	Required	Description
:integrationId	Yes	Integration UUID
:jobId	No	Specific job UUID. If omitted, all jobs in the queue are deleted.

---

11. Integration & Pipeline Statuses

Integration Statuses

Status	Description
inactive	Integration exists but has not started syncing
syncing	Initial sync pipeline is running
active	Initial pipeline completed; manual status/channel/payment mappings in the Hype Server back office are still required before order traffic
aborted	Pipeline failed or was manually aborted
error	Integration is in an error state

Create integration -> inactive -> syncing -> active
                                    |
                                    +-> aborted on failure or cancellation

After active, complete the manual mapping described below before enabling orders. failed is a pipeline status; an integration whose pipeline fails becomes aborted.

Pipeline Statuses

Status	Description
pending	Pipeline created but not yet started
processing	Pipeline is actively working through its steps
synced	All steps completed successfully
failed	A step failed -- pipeline stopped
stopped	Pipeline was manually stopped

---

12. Initial Sync Pipeline

When a new integration is created, HES runs a pipeline -- a strictly sequential series of steps that synchronize all entities between the Hype POS and your platform. The pipeline is built from both platform adapter configurations and filtered by the entity mappings defined for the integration.

Pipeline Steps (11 steps)

A standard hype-custom integration has 11 pipeline steps executed in this exact order:

Phase 1: Collect Hype data (steps 1-8)

HES fetches entities from Hype. Steps 1-5 create tasks for your platform; steps 6-8 store Hype values for manual mapping. The default status/channel/payment mappings do not define automatic record creation on the other platform.

Step	Entity	What Happens
1	Categories	HES fetches all categories from Hype POS, creates POST tasks for your platform. You poll, create them in your system, report back with your IDs.
2	Saloons	HES fetches all saloons from Hype POS, creates POST tasks for your platform.
3	Tables	HES fetches all non-virtual tables from Hype POS, creates POST tasks for your platform. Tables reference saloons synced in step 2.
4	Articles (Items)	HES fetches all menu items from Hype POS, creates POST tasks for your platform. Items reference categories synced in step 1. Item tasks carry no supplement data.
5	Supplements	HES fetches all menu-scoped supplements from Hype POS, creates POST tasks for your platform. These mappings are later reused for order item supplement references.
6	Order Request Statuses	HES stores Hype's order statuses as choices for manual pairing after activation.
7	Order Delivery Channels	HES stores Hype's delivery channels as choices for manual pairing after activation.
8	Order Payment Types	HES stores Hype's payment types as choices for manual pairing after activation.

Phase 2: Collect your platform's values (steps 9-11)

HES requests your platform's values through GET-type tasks and stores them as the other side of the choices for manual mapping. This does not automatically pair the values or create them in Hype POS.

Step	Entity	What Happens
9	Order Request Statuses	Answer the GET task on orderRequestStatus with an array of your order statuses, including stable IDs. HES stores these choices for manual pairing.
10	Order Delivery Channels	Answer the GET task on orderDeliveryChannels with an array of your delivery channels, including stable IDs. HES stores these choices for manual pairing.
11	Order Payment Types	Answer the GET task on orderPaymentTypes with an array of your payment types, including stable IDs. HES stores these choices for manual pairing.

Why This Order Matters

• Categories before Articles (steps 1 and 4): Articles reference categories via categoryId. The category entity value mapping must exist before HES can resolve category references in articles.
• Articles before Supplements (steps 4 and 5): Supplement payloads reference item mappings via articleId, so HES must synchronize items before menu-scoped supplements.
• Saloons before Tables (steps 2 and 3): Tables reference saloons via saloonId. The saloon entity value mapping must exist before HES can resolve table location references.
• Both sides before manual mapping: Steps 6-8 collect Hype's statuses, channels, and payment types; steps 9-11 collect yours. Both sets must be available before a person pairs them in the back office.

How Steps Advance

The pipeline processes one step at a time. From your platform's perspective:

1. Poll every enabled /tasks/hype-custom/{entity} endpoint.
2. Process each task according to its type and submit the result with PUT /tasks/hype-custom/{entity}.
3. Return stable IDs for records you create or match. HES records the results and establishes the corresponding ID mappings.
4. HES advances only after all work for the current step has finished. Monitor progress through GET /api/hype-custom/integrations/{id}?include=pipeline.
5. When all steps complete, the pipeline becomes synced and the integration becomes active. Complete the manual mappings below before sending orders.

The pipeline waits indefinitely. If your platform stops polling or reporting results, synchronization can remain in processing. If your side has no pending tasks but progress remains stalled, contact Hype support with the integration ID and pipeline message.

Your Responsibilities During Initial Sync

1. Poll frequently for tasks on all entity types during initial sync. The pipeline advances one entity type at a time, so tasks will appear sequentially -- first on /tasks/hype-custom/categories, then /tasks/hype-custom/saloons, /tasks/hype-custom/tables, /tasks/hype-custom/items, /tasks/hype-custom/supplements, etc.

2. Process every task promptly. The pipeline cannot advance to the next step until the source task response has been processed and every task produced by the current step is marked as synced via PUT responses.

3. Include your platform's id whenever an entity exists. This is critical -- HES uses these IDs to create entity value mappings that enable the bidirectional ID translation used in order processing. The only supported no-entity ACK for Hype Custom is saloon/table tasks when your platform does not model floor plans; if you ACK them with response: {}, do not send table references in later order requests.

4. For GET-type tasks (steps 9-11): Return all records of that entity type from your system in the response body. HES needs these as choices for the manual mapping step after activation.

5. Monitor progress via GET /api/hype-custom/integrations/:id?include=pipeline -- check pipeline.progress.step and pipeline.progress.from.

Manual Mapping After Activation

After the pipeline becomes synced and the integration becomes active, open the integration in the Hype Server back-office UI. Pair and save the corresponding values for:

• order request statuses
• order delivery channels
• order payment types

Cover every value used by orders or status updates. The pipeline collects the records; it does not choose these pairs automatically, even when names match. If a required value is missing, correct the source records or bootstrap responses and refresh them before mapping.

Do not enable order traffic until these mappings are saved and a test order has reached Hype with a status update returned to your platform. Review the mappings whenever new values are introduced.

Pipeline Failure & Recovery

No rollback. If a step fails, already-synced entities from previous steps remain in place. The pipeline simply stops.

On failure:

• The failing EntityTask is marked as ERROR with the error message
• The pipeline status becomes failed, the message field contains the error
• The integration status becomes aborted

Queue pause for missing dependencies: During ongoing sync (after the pipeline), if a sync job encounters an entity reference that hasn't been mapped yet (e.g., an order references an item not yet synced), the integration queue pauses for 60 seconds and automatically retries. This handles race conditions where entities arrive slightly out of order.

Recovery options (performed by Hype support):

• Re-triggering the full sync process

---

13. Ongoing Synchronization

Begin normal order traffic after the initial pipeline completes, the integration reaches active, the manual mappings are saved in the Hype Server back-office UI, and an end-to-end order check succeeds.

Hype -> Your Platform (entity changes)

1. A catalog change becomes available through HES as a task of type PUT.
2. Your platform polls: GET /tasks/hype-custom/items.
3. Your platform applies the change, keeping the record's existing ID.
4. Your platform reports: PUT /tasks/hype-custom/items (status: 200).

Your Platform -> Hype (new order)

1. A customer places an order on your platform.
2. Send POST /webhook/hype-custom/orderRequests with mapped IDs.
3. HES returns 204 and handles delivery asynchronously.
4. Confirm the order appears in Hype.
5. Poll GET /tasks/hype-custom/orderRequests for order status changes.
6. Apply each status change in your platform.
7. Submit the task result with PUT /tasks/hype-custom/orderRequests.

---

14. Quick Reference

All Endpoints

#	Method	URL	Description
1	GET	/tasks/hype-custom/items	Fetch pending item tasks
2	PUT	/tasks/hype-custom/items	Report item task results
3	GET	/tasks/hype-custom/categories	Fetch pending category tasks
4	PUT	/tasks/hype-custom/categories	Report category task results
5	GET	/tasks/hype-custom/supplements	Fetch pending supplement tasks
6	PUT	/tasks/hype-custom/supplements	Report supplement task results
7	GET	/tasks/hype-custom/saloons	Fetch pending saloon tasks
8	PUT	/tasks/hype-custom/saloons	Report saloon task results
9	GET	/tasks/hype-custom/tables	Fetch pending table tasks
10	PUT	/tasks/hype-custom/tables	Report table task results
11	GET	/tasks/hype-custom/orderRequests	Fetch pending order request tasks
12	PUT	/tasks/hype-custom/orderRequests	Report order request task results
13	GET	/tasks/hype-custom/orderDeliveryChannels	Fetch pending delivery channel tasks
14	PUT	/tasks/hype-custom/orderDeliveryChannels	Report delivery channel task results
15	GET	/tasks/hype-custom/orderPaymentTypes	Fetch pending payment type tasks
16	PUT	/tasks/hype-custom/orderPaymentTypes	Report payment type task results
17	GET	/tasks/hype-custom/orderRequestStatus	Fetch pending order status tasks
18	PUT	/tasks/hype-custom/orderRequestStatus	Report order status task results
19	POST	/webhook/hype-custom/orderRequests	Create an order request
20	PUT	/webhook/hype-custom/orderRequests	Update an order request
21	POST	/webhook/hype-custom/orderDeliveryChannels	Create a delivery channel
22	PUT	/webhook/hype-custom/orderDeliveryChannels	Update a delivery channel
23	POST	/webhook/hype-custom/orderPaymentTypes	Create a payment type
24	PUT	/webhook/hype-custom/orderPaymentTypes	Update a payment type
25	POST	/webhook/hype-custom/orderRequestStatus	Create an order status
26	PUT	/webhook/hype-custom/orderRequestStatus	Update an order status
27	GET	/api/hype-custom/integrations	List all integrations
28	GET	/api/hype-custom/integrations/:id	Get integration details
29	GET	/api/hype-custom/integrations/:id/queue-jobs	List queue jobs
30	DELETE	/api/hype-custom/integrations/:id/queue-jobs/:jobId	Delete queue job(s)

Entity Types Summary

Entity	Direction	Task URL Segment	Webhook URL Segment
Items	Hype -> External	items	--
Categories	Hype -> External	categories	--
Supplements	Hype -> External	supplements	--
Saloons	Hype -> External	saloons	--
Tables	Hype -> External	tables	--
Order Requests	Bidirectional	orderRequests	orderRequests
Delivery Channels	Bidirectional (initial sync)	orderDeliveryChannels	orderDeliveryChannels
Payment Types	Bidirectional (initial sync)	orderPaymentTypes	orderPaymentTypes
Order Statuses	Bidirectional (initial sync)	orderRequestStatus	orderRequestStatus

---

This document is maintained in the Hype Exchange Service repository and serves as the customer-facing reference for implementing the hype-custom integration adapter.