Events

Sending a template couples your application to messaging: the template name, its language, the order of its placeholders. Change the copy and you deploy code. Events invert that. Your application says what happened:

curl https://lazyapp.in/v1/events \
  -H "Authorization: Bearer $LAZYAPP_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1042-shipped" \
  -d '{
    "type": "order.shipped",
    "recipient": { "phone_number": "+919812345670" },
    "properties": {
      "order_id": "1042",
      "eta": "Thursday",
      "tracking_url": "https://acme.example/track/1042"
    }
  }'

LazyApp resolves the event to a template, maps the properties onto its placeholders, and sends. The mapping lives in your workspace — set it in the console or provision it over the API — so marketing can change the wording without touching your code.

Listing mappings

curl https://lazyapp.in/v1/event-mappings \
  -H "Authorization: Bearer $LAZYAPP_API_KEY"

Required scope: templates:read.

Provisioning mappings

Platforms can create or update mappings without the console:

curl -X PUT https://lazyapp.in/v1/event-mappings/provision \
  -H "Authorization: Bearer $LAZYAPP_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: acme-real-estate-mappings" \
  -d '{ "pack": "real_estate" }'

Or pass an explicit list (not both pack and mappings):

{
  "mappings": [
    {
      "event_type": "order.shipped",
      "template_name": "order_shipped",
      "language": "en",
      "body_variables": ["order_id", "eta"],
      "pricing_category": "utility"
    }
  ]
}

Required scope: templates:write. To also seed workflows and Flows for a vertical, use automation packs.

Addressing

By phone number:

{ "recipient": { "phone_number": "+919812345670" } }

or with type and value, the same shape as a contact:

{ "recipient": { "type": "phone_number", "value": "+919812345670" } }

Or by contact, when you already track people in LazyApp:

{ "recipient": { "type": "contact_id", "value": "9f8b1c2d-4e5f-4a6b-8c7d-0e1f2a3b4c5d" } }

Record without sending

Not every business event should message the customer. A lead being qualified, a visit booked by an agent or a ticket created are worth keeping, and worth starting a workflow from, without a WhatsApp message. Send "deliver": false:

{
  "type": "enquiry.received",
  "recipient": { "phone_number": "+919812345670" },
  "properties": { "stage": "qualified", "score": 72 },
  "deliver": false,
  "idempotency_key": "lead-42-qualified"
}

{ "uuid": null, "event_uuid": "7d1c…", "status": "recorded", "type": "enquiry.received" }

The answer is 202. The event appears in GET /v1/events with status recorded and starts api_event workflows. It needs no template mapping: a type with no mapping is refused only when you ask for it to be delivered.

Event types

type accepts the built-in library plus any event you define in your workspace. Defining your own also lets you declare a property schema, so a malformed event is rejected at the API rather than producing a message with an empty placeholder. Define a type over the API with PUT /v1/event-definitions/{type}. Namespace it (real_estate.visit_booked, clinic.appointment_booked) so two products sharing a workspace never fight over one type:

curl -X PUT https://lazyapp.in/v1/event-definitions/real_estate.visit_booked \
  -H "Authorization: Bearer $LAZYAPP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Visit booked",
    "schema": {
      "required": ["property_id"],
      "properties": {
        "property_id": { "type": "string" },
        "slot": { "enum": ["morning", "evening"] }
      }
    }
  }'

The call is idempotent, so run it from your setup script on every deploy. GET /v1/event-definitions lists your types, and DELETE /v1/event-definitions/{type} archives one: new events of that type are refused, and past ones stay in the history.

Idempotency

Events are the natural place for permanent deduplication. The body-level idempotency_key is enforced by a unique constraint, so one business event produces one message — forever, not just for 24 hours:

{ "idempotency_key": "order-1042-shipped" }

That matters when your own job runner might replay a task weeks later. See idempotency for how this differs from the header.

Replaying

If an event failed for a transient reason, replay it:

curl -X POST https://lazyapp.in/v1/events/{uuid}/replay \
  -H "Authorization: Bearer $LAZYAPP_API_KEY"

The replay runs under a fresh idempotency key, so the original deduplication does not block it.

Ingesting from another system

For a CRM or storefront that cannot be taught LazyApp’s event shape, there is a generic ingress:

curl https://lazyapp.in/v1/integrations/shopify/events \
  -H "Authorization: Bearer $LAZYAPP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"topic": "fulfillment/create", "order": {"id": 1042}}'

The body is handed to your workflows as the trigger payload, filtered by source, so an automation can be authored against whatever that system already sends.

Getting started

Core concepts

WhatsApp

Security

Billing

Sending

Receiving

Platforms

Migrating

Reference

Listing mappings

Provisioning mappings

Addressing

Record without sending

Event types

Idempotency

Replaying

Ingesting from another system

​Listing mappings

​Provisioning mappings

​Addressing

​Record without sending

​Event types

​Idempotency

​Replaying

​Ingesting from another system

Listing mappings

Provisioning mappings

Addressing

Record without sending

Event types

Idempotency

Replaying

Ingesting from another system