Sgcwebsockets Apis

sgcWebSockets Service Integrations

Fifteen integrations with third-party realtime and push services. They split into two families that are used quite differently, and picking the wrong mental model is the usual first mistake.

Socket-attached: TsgcWSAPI_SignalR, TsgcWSAPI_SignalRCore, TsgcWSAPI_SocketIO, TsgcWSAPI_Pusher, TsgcWSAPI_Discord and TsgcWSAPI_OpenAI. Each attaches to a TsgcWebSocketClient through Client, exactly like the protocol components elsewhere in the suite.

Standalone: everything else. AWS SQS, the three Google Cloud clients, Web Push, Telegram, WhatsApp and RCON are complete components with their own transport. They have no Client property and nothing to bind.

When to use this skill

• Talk to an ASP.NET SignalR or SignalR Core hub from Delphi
• Connect to a Socket.IO server
• Subscribe to Pusher channels, or trigger events on them
• Run a Discord bot: gateway events plus REST calls
• Use OpenAI's realtime WebSocket API
• Send Web Push notifications, or receive them in a server
• Publish to AWS SQS or Google Cloud Pub/Sub
• Send Firebase Cloud Messaging pushes, or read a Google Calendar
• Drive a Telegram or WhatsApp bot
• Send RCON commands to a game server

Units

The socket-attached ones also need sgcWebSocket for the transport and sgcWebSocket_Classes for TsgcWSConnection.

Before you start, ask the developer

Use a structured question tool if your host has one, for example Claude Code's AskUserQuestion. Otherwise ask in chat:

1. Which service, and which version of it? SignalR and SignalR Core are different protocols and different components. Picking wrong produces a connection that handshakes and then goes quiet.
2. Are credentials available? Every service here except RCON needs a token, key or service account. Read them from configuration, never from source.
3. Sending or receiving? Web Push has a client for sending and a server component for receiving. They are not interchangeable.
4. Is a bot framework already in place? Discord and Telegram bots usually need both the realtime gateway and REST calls, and this skill covers both.

Quickstart, SignalR Core

SignalR Core is RPC-shaped: you invoke a method on the hub by name, with arguments passed as an open array:

uses
  sgcWebSocket, sgcWebSocket_APIs, sgcWebSocket_Classes;

FClient := TsgcWebSocketClient.Create(Self);
FClient.URL := 'https://example.com/chathub';

FSignalR := TsgcWSAPI_SignalRCore.Create(Self);
FSignalR.Client := FClient;
FClient.Active := True;

// fire and forget
FSignalR.Invoke('SendMessage', ['alice', 'hello']);

// or wait for the hub's completion message
if FSignalR.InvokeAndWait('GetCount', [], 'inv-1', vCompletion) then
  ShowMessage(vCompletion.Result);

TSignalRCore_Completion is a record with InvocationId, Result, Error and Headers. A hub method that threw returns with Error populated and Result empty, so check Error before trusting Result.

InvokeStream starts a streaming invocation, and CancelInvocation stops one by its invocation id. The id is yours to choose and is how a reply is matched to its call.

Quickstart, Pusher

Pusher is channel-shaped, and the channel type matters because private and presence channels are authenticated differently:

FPusher.Client := FClient;
FPusher.Subscribe('orders');                              // public
FPusher.Subscribe('private-orders', pscPrivateChannel);   // needs auth
FPusher.Publish('new-order', 'orders', pscPublicChannel, '{"id":42}');

TriggerEvent posts an event through Pusher's REST side rather than the socket, which is what you want when the sending application is a server.

Socket.IO is thinner than it looks

TsgcWSAPI_SocketIO handles the Socket.IO handshake and framing, and that is all. It has no Emit method. You send with the transport client's WriteData and receive through OnMessage, with the component taking care of the protocol envelope around it. OnAfterConnect fires once the Socket.IO session, not just the socket, is established.

Discord is two APIs at once

The gateway delivers events over the socket, and everything you do goes through REST helpers on the same component:

FDiscord.Client := FClient;
vJson := FDiscord.POST_Request('/channels/123/messages', '{"content":"hi"}');

GET_Request, POST_Request, PUT_Request and PATCH_Request take a path relative to the Discord API root and return the raw response body.

The standalone components

These need no transport and no binding. Create, configure credentials, call:

• TsgcHTTPAWS_SQS_Client: queue send and receive
• TsgcHTTPGoogleCloud_PubSub_Client: publish and pull
• TsgcHTTPGoogleCloud_FCM_Client: Firebase push
• TsgcHTTPGoogleCloud_Calendar_Client: calendar read and write
• TsgcWebPush_Client: send a Web Push notification
• TsgcWSAPIServer_WebPush: the receiving side, attaches to a server
• TsgcTDLib_Telegram: Telegram via TDLib
• TsgcWhatsApp_Client: WhatsApp
• TsgcLib_RCON: RCON game server commands

Things that catch people out

• SignalR and SignalR Core are not the same protocol. The old one is TsgcWSAPI_SignalR, ASP.NET Core's is TsgcWSAPI_SignalRCore.
• Socket.IO has no Emit. Looking for one and not finding it is expected; write through the client instead.
• The socket-attached components need Client assigned, the standalone ones have no such property. Trying to bind a Google Cloud client to a WebSocket client will not compile.
• Pusher private and presence channels need an auth endpoint. Subscribing to private- anything without it fails at the subscription, not at connect.
• Discord's REST helpers take a path, not a full URL. Passing https://discord.com/api/... produces a malformed request.
• Google Cloud components authenticate with a service account, which is a JSON file. Never inline that file's contents into source.

Routing

• Find a component: reference/components-index.md lists every component, its unit, and its edition, grouped by Reg module.
• Uses clause: add the component's unit: value (shown on its API page) to your uses clause. Nothing compiles without it.
• API detail: reference/api/<Component>.md has the Properties, Events and Methods, each in both Delphi and C++Builder form.
• Option / enum / event types: property and event types link to reference/types/<TypeName>.md, which documents the sub-properties of option classes, the values of enums, and the parameter list of event handlers.
• Examples: examples/index.md is the full demo catalog; examples/<Component>.md is a focused, real usage snippet for the most-used components.
• Concepts: concepts/overview.md (getting started + uses-clause rule) and concepts/editions-and-features.md (which components your edition includes).
• Bundled resources: concepts/resources.md lists the browser-side assets (JavaScript, HTML, CSS) the server components serve or embed, so a browser client works without an external CDN.
• Version history: reference/history.md lists what changed in each sgcWebSockets release.

Editions

Components are gated by edition (Professional, Enterprise, All-Access) or by a feature define. Check the edition column in the components index, or concepts/editions-and-features.md, before relying on a component.

Only public and published members are documented. Method bodies, private fields and protected members are intentionally not included.