NotifyMe API Reference

Delivery, profile labels, and local messaging in one backend surface.

Use any device API key from the app’s API Keys screen as a Bearer token. The current backend exposes notification delivery, API key profile labels, local-first messaging, and export/import flows without requiring new tables for this phase.

NotifyMe Home

Access

Every request is sent over HTTPS and scoped to the device that owns the API key.

Authorization

Header

Always

Bearer <YOUR_DEVICE_API_KEY>

Content-Type

Header

Always

application/json for every NotifyMe POST route in this page.

Delivery endpoint

HTTP

Core

POST https://www.nextgenaischool.in/api/notifyme/send

Send Payload

The delivery API still centers on a compact notification payload, with profile labels derived from the authenticated API key.

title

string

Yes

Notification title shown in Android and stored in history.

body

string

Yes

Main message text for the push and history list.

notificationId

string

Optional stable identifier for callbacks, dedupe, or client correlation.

actionType

enum

Supported: open_home, open_history, open_updates, open_token, open_url, open_custom.

buttons

array

Up to three quick actions. Legacy buttonLabel/buttonAction still map to one button.

textReplyEnabled

boolean

Adds inline reply affordance to the notification shade.

callbackUrl

string

Registers a backend callback for button presses or inline replies.

curl -X POST https://www.nextgenaischool.in/api/notifyme/send \
  -H "Authorization: Bearer <YOUR_DEVICE_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Codex build complete",
    "body": "Project: NotifyMe\nTask: frontend refactor\nStatus: Success",
    "actionType": "open_history",
    "buttons": [{"label":"Open","action":"open"}]
  }'

Profile Labels And History Sync

NotifyMe now derives a safe source label from the authenticated API key profile. The raw key is never returned.

GET /api/notifyme/profile

read

Auth

Returns the current API key preview, safe sourceLabel, and local messaging profile state.

PUT /api/notifyme/profile

write

Auth

Updates profileLabel and/or username for the authenticated device identity.

GET /api/notifyme/history-sync

read

Auth

Returns stored notification history items with both sourceLabel and generatedBy.

{
  "profileLabel": "Codex Worker",
  "username": "lakshay"
}

Local Messaging Endpoints

The current messaging surface is username-based, text-only, local-first, and structured to accept encryption fields later.

GET /api/notifyme/messaging/users/:username

lookup

Auth

Checks if a username exists and whether it belongs to the current device identity.

GET /api/notifyme/messaging/conversations

list

Auth

Returns conversation summaries. Optional ?q= filters by peer username or message preview.

POST /api/notifyme/messaging/conversations

create

Auth

Creates or reuses a direct conversation using a target username. Optional initial text message is supported.

GET /api/notifyme/messaging/conversations/:conversationId

read

Auth

Returns one conversation with ordered text messages and encryption-ready metadata.

POST /api/notifyme/messaging/conversations/:conversationId/messages

write

Auth

Appends a text message to an existing direct conversation.

Export And Import

Data portability is part of the current backend contract, even though encryption and richer sync behavior can be layered on later.

GET /api/notifyme/messaging/export

export

Auth

Returns the current messaging profile, stored conversations, and portable metadata for backup or device transfer.

POST /api/notifyme/messaging/import

import

Auth

Imports previously exported conversations and remaps the current owner key when necessary.

Notes

Profile labels are safe identifiers only. NotifyMe does not return the raw API key in profile, history, or messaging responses.
Messaging is intentionally text-only in this phase. No attachments, reactions, stories, voice, or contact syncing are part of the current contract.
Conversation payloads already reserve room for encrypted bodies and key references, but actual end-to-end encryption is not enabled yet.
Username uniqueness is enforced case-insensitively by the current backend routing layer.