# Sgcwebsockets > Index of the eSeGeCe sgcWebSockets library for Delphi and C++Builder. Use to find which component does a job, to check which edition includes it, or to read what changed in a release. Routes to the specialist sgcwebsockets-* skills that carry the detailed API. - Skill: `esegece-com/sgcwebsockets` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add esegece-com/sgcwebsockets` - Raw SKILL.md: https://api.skillmd.com/api/skills/esegece-com/sgcwebsockets/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: esegece-com (https://skillmd.com/u/esegece-com) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/esegece-com/sgcwebsockets --- # sgcWebSockets This is the index for sgcWebSockets. It holds the full component list, the edition matrix and the version history, and nothing else. The detailed API, the types and the examples live in seventeen companion skills, one per area of the library. Use this skill to answer "which component do I need" and "is it in my edition". Then load the skill that owns that component and work there. ## Finding the right component `reference/components-index.md` lists all 222 components with their unit, their edition, and the skill that documents each one. That last column is the routing: find the component, load that skill. If you already know roughly what you are doing, go straight to the skill: | You want to | Skill | | --- | --- | | WebSocket client or server, proxy, load balancer, cluster, firewall | `sgcwebsockets-core` | | MQTT, STOMP, AMQP, Kafka, WAMP2, any external broker | `sgcwebsockets-mq` | | The sgc subprotocols: pub/sub, dataset, files, presence, WAMP1, E2EE | `sgcwebsockets-protocols` | | Binance, Kraken, Coinbase and the other trading venues | `sgcwebsockets-exchanges` | | LLMs, embeddings, vector stores, text to speech, MCP | `sgcwebsockets-ai` | | SignalR, Socket.IO, Pusher, Discord, Telegram, Google Cloud, AWS SQS | `sgcwebsockets-apis` | | HTTP/2, HTTP/3, QUIC, gRPC, REST server, TCP, UDP, WebView2 | `sgcwebsockets-http` | | OAuth2, JWT, WebAuthn, DPoP | `sgcwebsockets-auth` | | WebRTC, STUN, TURN, ICE, signalling | `sgcwebsockets-p2p` | | AWS IoT Core, Azure IoT Hub | `sgcwebsockets-iot` | | Server-rendered HTML pages | `sgcwebsockets-html-core`, then the widget skill | The sgcHTML widgets split six ways: `-html-layout` for page structure, `-html-forms` for inputs, `-html-data` for grids and schedulers, `-html-charts` for charts and indicators, `-html-ui` for modals and media, and `-html-auth` for login and chat panels. ## Two rules that apply everywhere **Nothing compiles without the right unit.** Every API page states its `unit:` at the top, and that unit must be in your `uses` clause. This is the single most common reason generated sgcWebSockets code fails to build. **Most protocol and API components are not standalone.** They attach to a `TsgcWebSocketClient` or a `TsgcWebSocketServer` through a `Client` or `Server` property, and one transport carries one protocol. The exceptions are the IoT clients and the standalone HTTP clients, which own their own transport and are started with `Active := True`. ## Editions `concepts/editions-and-features.md` groups every component by the minimum edition that includes it. Check it before recommending a component, because the answer to "the component is not on my palette" is usually the edition rather than the installation. sgcHTML is the narrowest: All-Access only, Indy required, and unavailable on Android and iOS. ## What is documented, and what is not These skills carry the public and published API: properties, events, methods, their types, and the unit each component lives in. Method bodies, private fields and protected members are deliberately excluded, so the skills describe the shape of the library without exposing its source. That has one consequence worth knowing when you use them: a value that only ever appears as a method parameter may not have its own type page. If you need an enumeration's values and cannot find the page, say so rather than guessing an identifier, because a plausible-looking wrong constant costs more time than the question does. ## Version history `reference/history.md` lists what changed in each release. It is the place to check when an API in a customer's code does not match what these skills describe, because the answer is often that they are on an older build. ## Routing - **Find a component**: `reference/components-index.md` lists every component, its `unit`, its edition, and the `skill` that documents it. - **Then load that skill**: the API page, the option / enum / event type pages and the examples for a component live in the skill named in its row, not here. - **Uses clause**: add the component's `unit:` value to your `uses` clause. Nothing compiles without it. - **Editions**: `concepts/editions-and-features.md` groups every component by the minimum edition that includes it. - **Concepts**: `concepts/overview.md` (getting started + uses-clause rule). - **Version history**: `reference/history.md` lists what changed in each sgcWebSockets release.