6 Limitations and Constraints
When implementing the Oracle Hospitality Integration Platform (OHIP) Streaming API, it is essential to be aware of certain limitations and constraints to ensure optimal performance and compliance with system requirements.
Application Registration Limits
Each OHIP Developer Portal account can register up to 100 applications.
Streaming API Constraints
Single Consuming Client: Only one client can be connected to consume events from a single chain in a single gateway using a single application key. Attempting to connect multiple clients simultaneously will result in a 4409 error.
Per-Chain Concurrency: The single-consumer limit is enforced per (appKey, chainCode, gateway). Concurrent connections using the same appKey to different chains are permitted, provided each connection uses credentials/approvals for its respective chain.
Application Scope: Customer-owned applications are chain-scoped. Customers must create a separate application (and app key) under each chain they wish to connect. Partner-owned applications may connect to multiple chains using the same app key, provided subscriptions are configured and approvals are granted for each chain.
Connection Frequency: Streaming consumers are expected to remain connected continuously. If a disconnection occurs, the consumer must reconnect within 24 hours. Failing to do so requires sending the "offset" input parameter with the value of the last received offset upon reconnection.
Connection Reestablishment: Ensure a minimum of 10 seconds between sending the "complete" message to close a WebSocket connection and sending the next "subscribe" message to reopen it.
Header Size Limitations
The total size of all HTTP headers, including the OAuth token, application key, x-request-id, and others, must not exceed 8KB.
API Throttling
- Up to 12 requests per minute are allowed.
- A short-term burst of up to 100 requests per minute may be permitted.
Exceeding these limits may result in additional delays or HTTP 429 ("Too Many Requests") responses.
Delivery Semantics
No server‑side acknowledgments or dead‑letter queue.
The Streaming API uses GraphQL over WebSocket push; there is no application‑level ACK that the server requires or waits for before advancing the stream.
The platform does not provide a server‑managed dead‑letter queue (DLQ). If your consumer cannot process an event, you must handle it within your application.
Delivery is at‑least‑once and strictly ordered per (appKey, chainCode, gateway) while a single consumer is active.
Consumer Responsibilities
- Persist metadata.offset and metadata.uniqueEventId only after successful processing to treat that persistence as your "acknowledgment."
- Implement idempotency and duplicate suppression using offset and uniqueEventId.
- For "poison" messages that repeatedly fail your business processing, divert to an application‑managed DLQ (for example, a Kafka/RabbitMQ/SQS topic/queue or a durable store) with the original payload and context, and then continue consuming the stream.
- Use replay with your saved offset to recover after outages. Events are retained for 7 days.
By understanding and adhering to these limitations and constraints, you can ensure a more efficient and reliable integration with the OHIP Streaming API.