Skip to content

Core Concepts

PushGo can be understood as a synchronization path from your scripts, services, or devices to the clients subscribed to a channel. It does not only turn text into a system notification; its clients also project Event lifecycles and Thing state from the accepted patches so history, filtering, and automation stay structured.

Sender -> Gateway -> Channel -> Subscribed devices
|
+-> Message / Event / Thing
  • Sender: your script, server, Home Assistant, CI/CD pipeline, or AI assistant.
  • Gateway: validates and durably accepts requests, stores operational delivery state, selects delivery paths, and dispatches data.
  • Channel: the communication space subscribed to by one or more devices. Requests need a channel ID and password.
  • Client: Apple clients receive through APNs; Android clients can use FCM plus private transports.
  • Data model: PushGo separates one-off alerts, lifecycle processes, and persistent state into different objects.

Channel: Permission and Subscription Boundary

Section titled “Channel: Permission and Subscription Boundary”

A channel is PushGo’s basic boundary. Multiple devices can subscribe to one channel, and multiple senders can write to it if they know the credentials.

ConceptPurpose
channel_idIdentifies where the request is sent.
passwordAuthorizes writes to the channel.
Subscribed devicesReceive content accepted for the channel.

The channel password is not the gateway administrator password. Public and private gateways both use channel-level authorization; private gateways may also require a gateway-level Bearer token.

When the Gateway receives a request, it:

  1. Validates the request, channel credentials, and optional gateway Bearer token.
  2. Durably records the submission and operational delivery state; it does not merge Event/Thing patches into a canonical server-side entity record.
  3. Dispatches to subscribed devices through APNs, FCM, or Android private transports.

Subscribed clients persist and project Event/Thing history and current state. The IDs correlate those patches; update routes validate their format but do not require a prior server-side create record. The send response acknowledges durable Gateway acceptance. Delivery is asynchronous: use the returned op_id for coarse sender status, but do not treat it as a provider-success or device-display receipt.

PushGo’s core idea is not “many notification fields”; it is using different models for different business objects.

ModelRepresentsExamplesMain API
MessageOne-off alertDisk warning, backup completed, price droppedPOST /message
EventProcess with updates and an endDeployment, incident handling, door open to closed/event/create, /event/update, /event/close
ThingPersistent entity stateNAS, sensor, room, network service/thing/create, /thing/update, /thing/archive, /thing/delete

Ask one question first: are you notifying about something, tracking a process, or synchronizing an object’s current state?

PushGo does not force every platform through the same background connection.

PlatformPrimary pathNotes
Apple platformsAPNsSystem-managed delivery for iOS, macOS, and watchOS.
AndroidFCM + private transportsFCM for wake-up; private transports for lower-latency sync.
Self-hosted GatewayDeployment-dependentCan enable WSS, QUIC, Raw TCP, and MQTT 5 for Android private transports.

See Apps and Platform Support for client capabilities.

LayerWhat it solves
Channel passwordPrevents unauthorized writes to a channel.
Gateway Bearer tokenRestricts who can call a private Gateway instance.
HTTPS / TLSProtects credentials and requests in transit.
E2EE ciphertextLets clients decrypt sensitive business fields locally while the Gateway only relays ciphertext.
MCP OAuthLets AI assistants act within authorized channel scopes without directly holding channel passwords.

If you only want to send your first test notification, understand Channel and Message first. Read the data model, authentication, and self-hosting guides when you need long-lived state or your own Gateway.