Using with Lovable

Meta WhatsApp Coexistence is supported on Notifyer System. You do not need to delete the WhatsApp Business app or stop using the number on your phone. After Embedded Signup, the same number works in the WhatsApp Business app, the Notifyer chat inbox, and automations (Make, Zapier, n8n, API, and webhooks) at the same time.

Lovable’s web agent does not read skill files from .agents/skills/ or .cursor/skills/ — it only reads Project knowledge, Workspace knowledge, AGENTS.md, and CLAUDE.md from your GitHub repo. The npx skills add CLI has no direct effect on what Lovable sees.However, Lovable projects are GitHub-backed. If you also work on the same project locally in Cursor (a common hybrid workflow), you should install the skills there too — see the Cursor guide.

How Lovable reads context

Lovable’s agent considers several context sources when generating code:

Source	How to set it	Scope
Project knowledge	Project settings → Knowledge	One project
Workspace knowledge	Settings → Knowledge	All projects in workspace
`AGENTS.md` / `CLAUDE.md`	Root of the GitHub repo linked to the project	Always loaded regardless of session length
Integration knowledge	Via connected services (e.g. Supabase)	Per integration

AGENTS.md and CLAUDE.md at the repo root are always read by Lovable, even in very long sessions where project or workspace knowledge may not always be followed consistently. Use them for rules that must never be lost.

For Notifyer integrations, the most reliable approach is to put the critical API context in Project knowledge and keep the AGENTS.md file for structural rules that must persist across long sessions.

Option 1 — Project Knowledge (recommended)

Add the following to your project’s Project settings → Knowledge. This tells Lovable’s agent exactly how to call the Notifyer API when building your app.

Notifyer WhatsApp API integration

Base URL: stored in env var NOTIFYER_API_BASE_URL (e.g. https://api.insightssystem.com)
Auth token: stored in env var NOTIFYER_API_TOKEN (JWT from login)

Auth headers:
- Console API (templates, bots, broadcasts, webhooks):
    Authorization: Bearer <NOTIFYER_API_TOKEN>
    Origin: https://console.notifyer-systems.com
- Chat API (recipients, messaging, labels, handoff):
    Authorization: <NOTIFYER_API_TOKEN>  (no Bearer prefix)
    Origin: https://chat.notifyer-systems.com

Key API groups:
- /api:AFRA_QCy/ — templates
- /api:ox_LN9zX/ — bots
- /api:Mk_r6mq0/ — broadcasts
- /api:bVXsw_FD/ — chat recipients and messaging
- /api:qh9OQ3OW/ — message logs and analytics
- /api:0hqyGRIz/ — webhooks (enable incoming AND outgoing)

Critical rules:
- Never hardcode NOTIFYER_API_TOKEN in source code — always use env vars.
- Text and attachment messages require the recipient to have messaged in the last 24 hours.
  If window is closed, use a template message instead.
- global_label is a string[] of label names, not IDs.
- PATCH /web/recipient/:id requires the full recipient body (fetch first, then patch).
- Schedule timestamp is ms since epoch; 0 means immediate send.
- NOTIFYER_API_BASE_URL must be HTTPS — reject any http:// value.
- Meta WhatsApp Coexistence is supported. Do NOT tell users to delete the WhatsApp Business app.
- Webhooks fire for incoming AND outgoing messages (including hand-typed WhatsApp Business app replies).
  Payload fields: incoming_message (boolean), send_by ("WhatsApp App" | teammate name | automation name),
  was_message_by_human (boolean). last_messages is often a JSON string — parse it.
- Full webhook reference: https://docs.whatsable.app/guides/notifyer-system/api/incoming-message
- Coexistence / embedding: https://docs.whatsable.app/guides/notifyer-system/embedding-process

Reference:
- Full API documentation: https://github.com/Whatsable/whatsapp-business-agent-skills
- Script reference: skills/chat-notifyer/scripts/ and skills/automate-notifyer/scripts/

Project Knowledge supports up to 10,000 characters. The block above is intentionally concise. Expand it with specific endpoint shapes or payload examples if your project needs precise API call generation.

Option 2 — AGENTS.md in your GitHub repo

For rules that must survive long Lovable chat sessions, add an AGENTS.md file to the root of the GitHub repository linked to your Lovable project. Lovable always reads root-level AGENTS.md files regardless of session length. Create AGENTS.md in your repo root:

# Notifyer WhatsApp Integration Rules

## Authentication
- Console API: `Authorization: Bearer ${NOTIFYER_API_TOKEN}` + `Origin: https://console.notifyer-systems.com`
- Chat API: `Authorization: ${NOTIFYER_API_TOKEN}` (no Bearer) + `Origin: https://chat.notifyer-systems.com`
- Base URL from `NOTIFYER_API_BASE_URL` env var (always HTTPS)

## 24-hour messaging window
- Free-text and media can only be sent if the recipient messaged us within the last 24 hours
- If window is closed, use a template message
- Check window via GET /api:bVXsw_FD/web/recipient — look at expiration_timestamp

## Coexistence and webhooks
- Do NOT tell users to delete the WhatsApp Business app. Meta WhatsApp Coexistence is supported.
- Webhooks fire for incoming AND outgoing messages, including hand-typed WhatsApp Business app replies.
- Payload: `incoming_message` (boolean), `send_by` (`WhatsApp App` | teammate name | automation), `was_message_by_human` (boolean)
- Docs: https://docs.whatsable.app/guides/notifyer-system/api/incoming-message

## Safe PATCH pattern
- Before PATCH /web/recipient/:id, always GET the full record first
- Include all existing fields in the PATCH body (name, phone_number, phone_number_string,
  global_label, is_ai_assistant, note) to prevent accidental data wipe

## Environment variables
- NOTIFYER_API_BASE_URL — required
- NOTIFYER_API_TOKEN — required, JWT from login
- Never commit tokens to Git

Example Lovable prompts

With the project knowledge or AGENTS.md in place, use Lovable’s Agent mode to build Notifyer-powered features:

Send a WhatsApp message from a form

Add a "Send WhatsApp" button to the CustomerDetail page.
When clicked, it should call a Supabase Edge Function that sends a WhatsApp text message
via the Notifyer Chat API to the customer's phone number.
Use NOTIFYER_API_BASE_URL and NOTIFYER_API_TOKEN from environment variables.
Only send if the 24-hour window is open; otherwise show an error: "Window closed — use a template."

Send a template when window is closed

In the CustomerDetail page, add a "Send Reminder" button.
The Edge Function should first check the recipient's expiration_timestamp.
If the 24h window is open, send a free-text message.
If closed, send the payment_reminder WhatsApp template instead.
Both paths use the Notifyer Chat API with the correct auth header (no Bearer prefix).

Broadcast from the dashboard

Add a "Send Broadcast" section to the Marketing page.
It should let the user pick an approved template from a dropdown (fetched from
GET /api:AFRA_QCy/templates_web on the Notifyer Console API with Bearer auth),
upload a CSV of phone numbers, and trigger a broadcast via the Notifyer API.

Webhook receiver

Create a Supabase Edge Function at /notifyer-webhook that receives POST requests
from Notifyer's IO webhook. Validate the HMAC-SHA256 signature using NOTIFYER_WEBHOOK_SECRET.
The webhook fires for incoming AND outgoing messages (including replies typed in the
WhatsApp Business app — coexistence is supported; do not tell users to delete the app).
Insert a row into the messages table with:
  { phone, body, direction: incoming_message ? "inbound" : "outbound",
    send_by, was_message_by_human, received_at }
When incoming_message is false, send_by is "WhatsApp App" (phone), a teammate name
(Notifyer inbox), or an automation name.

Label and handoff from the app UI

In the ConversationView component, add two buttons:
1. "Assign to Human" — calls PATCH /api:bVXsw_FD/web/recipient/:id with is_ai_assistant: false
   using the Notifyer Chat API (Authorization: <token> without Bearer).
2. "Assign Label" — shows a dropdown of available labels and calls the same PATCH endpoint
   with the updated global_label array.
Both should fetch the full recipient record first before patching.

Incoming and outgoing WhatsApp messages

Notifyer delivers both incoming and outgoing messages to your webhook or automation trigger — including messages typed by hand in the WhatsApp Business app on your phone. This is possible because Notifyer supports Meta WhatsApp Coexistence. You keep using WhatsApp Business on your phone; those hand-typed replies still reach an external webhook and can start an automation. They are not limited to the Notifyer web inbox.

Trigger n8n (or any webhook) from WhatsApp messages — including replies typed in the WhatsApp Business app

The payload is the same whether you use n8n, Make, Zapier, or a custom webhook. Watch the walkthrough on YouTube.

Direction, sending system, and team member

Use these three fields to tell what happened and who sent it:

boolean

true when a contact sent a message to your business. false when your business sent a message to the contact (outgoing). Filter on this field to run logic only for one direction.

string

Which system or person sent an outgoing message:

`send_by` value	Meaning
`WhatsApp App`	Typed by hand in the WhatsApp Business app on a phone
A team member’s name (for example `Axel Meta`)	Sent from the Notifyer chat inbox by that logged-in user
An automation or app name (Make, Zapier, n8n, API, bot)	Sent by that integration or bot

Empty or omitted on incoming messages.

boolean

true when a person sent the message (WhatsApp Business app or Notifyer chat inbox). false when a bot or automation sent it. Combine with send_by to see both whether a human sent it and which teammate or system did.

Example payload: message typed on the phone

This is the JSON Notifyer POSTs when someone types a reply in the WhatsApp Business app. incoming_message is false, send_by is "WhatsApp App", and was_message_by_human is true.

{
  "last_messages": "[{\"type\":\"bot\",\"content\":\"Hello n8n\",\"timestamp\":\"2026-08-15T12:24:47.000Z\",\"content_type\":\"text\"},{\"type\":\"user\",\"content\":\"hi\",\"timestamp\":\"2026-08-12T12:27:42.746Z\",\"content_type\":\"text\"}]",
  "conversation_paragraph": "Bot (12:24:47 PM): Hello n8n ; User (12:27:42 PM): hi",
  "phone_number": 14155552671,
  "recipient_name": "Alex Martinez",
  "user_id": "158c59e1-ea85-4d0b-b70c-65328ba67a8e",
  "last_message_of_user": "hi",
  "last_message_of_bot": "Hello n8n",
  "message_type": "text",
  "user_last_message_time": 1786722580,
  "bot_last_message_time": 1786797014,
  "attachment_url": null,
  "note": "email: alex\nName: Alex",
  "note_automation": "email: alex\nName: Alex",
  "labels": "n8n, webhook-test",
  "incoming_message": false,
  "send_by": "WhatsApp App",
  "was_message_by_human": true
}

last_message_of_bot is the last message your business sent — whether a human typed it in the WhatsApp Business app or the Notifyer inbox, or a bot/automation sent it. last_messages is a JSON string of the last ~20 messages (parse it before iterating). phone_number may arrive as a number rather than a string.

When the same person sends from the Notifyer chat inbox instead of the phone app, the payload is identical except:

{
  "incoming_message": false,
  "send_by": "Axel Meta",
  "was_message_by_human": true
}

Using Plan mode before building

For complex integrations, click Plan next to the message input to switch to Plan mode before any code is written. Plan mode never modifies your code — it only reasons and proposes an approach.

I want to integrate Notifyer WhatsApp messaging into this app.
We need to: send template messages when a new order is created, receive inbound
AND outbound messages via webhook (including WhatsApp Business app replies;
incoming_message, send_by, was_message_by_human), and show chat history in the CustomerDetail page.
What's the best architecture using Supabase Edge Functions?

When you’re happy with the plan, approve it and Lovable automatically switches to Agent mode to implement each piece. The approved plan is saved to .lovable/plan.md in your project.

Environment variables by backend

Lovable supports two distinct backends. The env var workflow is different for each.

Lovable Cloud (built-in backend)
Supabase integration (external Supabase account)
External / self-hosted deployment

Lovable Cloud is Lovable’s own full-stack hosting platform — no external Supabase account needed. It handles the backend automatically.When Lovable generates an Edge Function that calls the Notifyer API, instruct it to read secrets from environment variables:

Store NOTIFYER_API_BASE_URL and NOTIFYER_API_TOKEN as secrets in
Lovable Cloud and read them inside the Edge Function with
Deno.env.get("NOTIFYER_API_TOKEN").

Lovable Cloud manages the secret injection automatically as part of the Cloud environment. You can review and manage Cloud settings via Connectors → App connectors → Lovable Cloud → Manage permissions.

If your project uses the Supabase integration (you connected your own Supabase project via Project settings → Integrations → Supabase):

Open your Supabase dashboard → Settings → Edge Functions → Secrets
Add NOTIFYER_API_BASE_URL and NOTIFYER_API_TOKEN as secrets
Reference them in Edge Functions with Deno.env.get("NOTIFYER_API_TOKEN")

Never pass NOTIFYER_API_TOKEN as a hardcoded string in Edge Function code — it would be visible in your GitHub repository.

If you’ve exported your Lovable project to GitHub and are hosting it yourself, configure environment variables through your host’s standard mechanism (e.g. Vercel env vars, Railway secrets, .env on a VPS).

Important constraints

These operations cannot be done via Lovable or any API — they require the Notifyer Console web UI:

Initial WhatsApp number connection (embedded signup / QR scan)
Billing and Stripe plan changes
Meta template approval (timing is controlled by Meta, not the API)

Quickstart
Auth & environment
Security
Using with Cursor — install skills locally if you work on the Lovable project in Cursor
Lovable Agent mode docs
Lovable Knowledge docs
Lovable Plan mode docs

Get Started

Whatsable (formerly Notifyer System)

WhatsApp Cloud API errors

How Lovable reads context

Option 1 — Project Knowledge (recommended)

Option 2 — AGENTS.md in your GitHub repo

Example Lovable prompts

Send a WhatsApp message from a form

Send a template when window is closed

Broadcast from the dashboard

Webhook receiver

Label and handoff from the app UI

Incoming and outgoing WhatsApp messages

Direction, sending system, and team member

Example payload: message typed on the phone

Using Plan mode before building

Environment variables by backend

Important constraints

​How Lovable reads context

​Option 1 — Project Knowledge (recommended)

​Option 2 — AGENTS.md in your GitHub repo

​Example Lovable prompts

​Send a WhatsApp message from a form

​Send a template when window is closed

​Broadcast from the dashboard

​Webhook receiver

​Label and handoff from the app UI

​Incoming and outgoing WhatsApp messages

​Direction, sending system, and team member

​Example payload: message typed on the phone

​Using Plan mode before building

​Environment variables by backend

​Important constraints

​Related pages

How Lovable reads context

Option 1 — Project Knowledge (recommended)

Option 2 — AGENTS.md in your GitHub repo

Example Lovable prompts

Send a WhatsApp message from a form

Send a template when window is closed

Broadcast from the dashboard

Webhook receiver

Label and handoff from the app UI

Incoming and outgoing WhatsApp messages

Direction, sending system, and team member

Example payload: message typed on the phone

Using Plan mode before building

Environment variables by backend

Important constraints

Related pages