Odin MaxCode Instead of Dozens of Keys: How PushMeld Adds Notifications Where They Didn’t Exist Before

Let's imagine a home computer that creates backups of important files every night. The result is recorded in the system log: the operation completed successfully or an error occurred.

Technically, everything works. The inconvenience arises in the morning: a person has to manually open the log and check the result. The program has no mobile app, notifications from developers are not provided, and building separate infrastructure just for one function is not practical.

Using PushMeld, a simple request can be added to this process. After completing the backup, a message will arrive on the phone: a copy was created or an error occurred. If needed, the same notification can be received via email.

The core idea is based on MaxCode — a unified secure code through which PushMeld receives all the necessary information for subsequent notification delivery.

When I first learned about the project, I found MaxCode to be its most interesting part. Push notifications and email have been around for a long time. What’s more important is that the original program no longer controls their delivery. It only reports the event to PushMeld, and everything else happens outside of it.

Background context: PushMeld is part of the MELD® system, developed by DigiMeld UG.

The Source Knows Only About the Event

Standard notification integration quickly becomes cluttered with technical details. You need to define the project, configure access, store keys, consider device tokens, set up email delivery, and understand the requirements of different mobile platforms.

PushMeld moves all this from the source system into a separate manageable framework.

The backup program only knows one thing: whether the operation completed successfully or with an error. It transmits MaxCode, the message header, and text.

It does not need to know:

• how many devices are connected to the project;

• which phone is currently active;

• through which provider the push should pass;

• whether email delivery is enabled;

• whether the user has a new smartphone;

• if the old tablet was disconnected;

• who should receive a particular notification.

All of this is determined within PushMeld.

In my opinion, the main architectural idea of the project lies here: MaxCode transfers notification management from the program where the event occurred to the system responsible for delivery.

One MaxCode Instead of a Set of Keys

Typically, when connecting an external service, you have to work with multiple entities. A project ID, an access key, and additionally secrets, device tokens, and provider-specific settings are used.

MaxCode consolidates everything needed for sending into a single secure code.

A unique MaxCode is created for each project. It combines project identification, the right to send, and data allowing PushMeld to apply the current delivery configuration.

The sending system does not need to store separately:

• project ID;

• API key and additional secret;

• connected device tokens;

• parameters for each recipient;

• keys of different push providers;

• separate settings for push and email.

Simply adding one MaxCode to the program, website, or script allows PushMeld to determine the project, validate the request, find connected devices, and select available channels.

Therefore, MaxCode should not be perceived as just another key added alongside others. Its purpose is to replace the entire set of fragmented keys, tokens, and identifiers with a single code.

Notification From Where It’s Not Provided

MaxCode can be used in any system capable of making an HTTP request either directly or via a small auxiliary script.

For example, PushMeld can notify when:

• a home server stops responding;

• a backup completes or ends in error;

• a custom script performs a long task;

• a 3D printer finishes printing;

• a sensor detects a leak;

• a door opens or an alarm triggers;

• important information appears on a website;

• a product price changes;

• free space for writing appears;

• an old program finishes processing a large file;

• a small online store receives a new order.

Each of these sources might not have a dedicated app. Some devices can only access a specified address, others can run a user command, and some can be supplemented with a short automation script.

This is enough to transmit the event to PushMeld.

In doing so, the source does not turn into an independent notification service. It simply records what happened and sends a message with MaxCode. Everything else — recipients, devices, channels, and technical routing — remains managed by PushMeld.

Not Only Push, But Also Email

The name PushMeld is primarily associated with notifications on phones, but the project’s capabilities are not limited to that.

Delivery can be via push, email, or both channels — depending on project settings and available options.

For example, a message confirming a successful backup can be shown on the phone. Serious errors can additionally be sent via email.

The original program performs the same request with MaxCode in both cases. It does not need to set up an email server separately, store its settings, or create a second independent scenario.

The decision on delivery channels is made within PushMeld. If later the user adds an email to an existing project, the backup script does not need to be reconfigured.

At the same time, email is used here not as a mass mailing tool, but as a supplementary way to inform about an event from the connected project.

One Project — One Source of Events

Projects allow for segmenting notifications according to their purpose.

An ordinary user might create, for example:

• HomeServer — status of the home server;

• Backups — backup results;

• SmartHome — sensors and home automation;

• PriceMonitor — price changes;

• Website — new inquiries from the personal website.

Each project receives its own MaxCode. This allows home automation to avoid using website codes, and price monitoring to remain separate from backups.

It’s immediately clear where the message came from and what task it relates to.

This separation is especially useful as the number of sources grows. Instead of one shared stream, a person gets several independent channels, each with its own delivery settings.

No Need to Change the Program When Getting a New Phone

A typical push token is associated with a specific application installed on a particular device.

If a person has two phones and a tablet, this already involves multiple tokens. After reinstalling the app or replacing the device, a token may change or stop working.

MaxCode exists above this level. It relates to the project, not to a single phone.

The user decides which devices are linked to the project and should receive messages. For instance, notifications from the home server can go to a personal phone and tablet, while events from the work website go only to a company phone.

If a person buys a new phone or disables an old device, the original script continues to use the same MaxCode. The list of current recipients is updated inside PushMeld.

The same applies when adding an email or changing other delivery parameters.

This is why MaxCode is not just a way to reduce the number of keys. It creates a boundary between the event and its subsequent route. Everything beyond this boundary can be changed without modifying the source program.

Free for Standard Tasks

Infrastructure products are often described through corporate systems, server commands, and large data volumes. Because of this, it might seem that PushMeld is aimed solely at professional developers and companies.

In practice, you can start with simple household tasks.

The app itself is free. The main features of MaxCode also work without payment within available free limits. A person can create a project, connect a device, and receive notifications from their server, website, script, or home automation.

This is not a temporary demo mode that stops working after getting acquainted with the product. For everyday scenarios, the free features might be sufficient.

Paid plans are needed when request volumes increase, additional features are required, or the system is used at scale.

One Principle for Individuals and Businesses

The mechanics of MaxCode remain unchanged regardless of task size.

The person receives a notification about the backup completion. A small workshop finds out that a 3D printer finished a long print. An online store gets a new order. The tech team is notified of a server error.

The volume and number of projects may vary, but the principle remains the same.

Imagine an organization with three sources of events:

• Orders — new orders;

• Payments — incoming payments and refunds;

• ServerStatus — technical errors.

Each has its own MaxCode and configured devices. Orders can go to the owner and manager, financial events to responsible personnel, and server issues to technical specialists.

The company’s system in all cases essentially does the same: transmits the event content and the corresponding project’s MaxCode.

If staff or devices change, or delivery methods are updated, the source systems do not need reconfiguration. Management stays within PushMeld.

APNs, FCM, and HMS Remain Outside the Program

For push delivery on different devices, APNs, FCM, or HMS can be used. Each provider has its own rules, tokens, and technical features.

Typically, these differences are considered during the development of the sending system. With PushMeld, they are outside of MaxCode.

The home server, website, or script does not determine which phone the recipient is using or through which infrastructure the message should pass. It makes a single request, and PushMeld chooses the necessary route.

MaxCode does not replace infrastructure like Apple, Google, or Huawei. It creates a unified access point before them.

This way, the source system does not need to change as user devices evolve. Today, the message might go through FCM, tomorrow through APNs, and later a new phone or email could be added to the project. The program that reports the event remains unaffected.

MaxCode and Regular API Key — Not the Same

A typical API key usually only grants access to a service. After verifying the key, the system still needs to separately identify the project, recipients, and delivery method.

MaxCode consolidates this context into a single code.

It allows PushMeld to recognize the project, verify the request, and apply current settings. The external program sends MaxCode and the event content without managing further routing.

A quick way to put it: an API key grants access to a function, while MaxCode simultaneously defines the context in which this function should be executed.

Notification as a Plug-in Option

After getting familiar with PushMeld, I wouldn’t simply call it an app for push notifications.

More precisely, it’s a way to add notifications where there were none before, and then manage them independently of the original program.

The source can be a home server, sensor, old app, online store, custom script, or internal company system. If it can execute an HTTP request on its own or via a small adapter, the event can be transmitted to PushMeld.

Next, MaxCode creates the boundary between the event and its delivery. On one side is the program that reports what happened. On the other side is PushMeld, which determines the project, devices, channels, and technical route.

Therefore, the most important feature of MaxCode is not just replacing multiple keys with one. It transfers notification management beyond the source system.

You can replace the phone, add an email, disable an old device, or change the delivery route. The program will continue doing its core task: reporting the event.