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; it also preserves event lifecycles and entity state 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 requests, stores 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. Creates or updates Message, Event, or Thing state.
  3. Dispatches to subscribed devices through APNs, FCM, or Android private transports.

The HTTP response means whether the Gateway accepted the request. Actual system notification delivery is asynchronous, so accepted means the request entered the dispatch path, not that every device has already displayed it.

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, and Raw TCP 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.