Panel webhooks

Panel webhooks are the notifications a store registers itself on the API screen, Webhooks tab. For every chosen event — order paid, Pix generated, customer created and others — Appmax sends a POST with the event data to the store's URL.

Not the same as Appstore webhooks

Developers of an app receive the Appstore webhooks, with a different envelope (app_id, site_id, external_key) and a different event list. This page is only for those integrating their own store.

Using an AI assistant

The context from the AI guide (API screen) already tells the assistant the store receives these webhooks and points to this page. Paste the context at the start of the conversation: the documentation MCP does not index this page yet and, on its own, leads the assistant to the Appstore webhooks.

How the delivery arrives

Every event produces a POST with a JSON body and three top-level fields:

{
  "environment": "production",
  "event": "OrderPaid",
  "data": { "id": 99042, "status": "aprovado", "...": "..." }
}

Field	Description
environment	Environment that produced the event. Sandbox and Production both send production; do not use this field to tell environments apart — use a different URL in each one.
event	Event name. It is the identifier from the table below with an uppercase first letter (orderPaid → OrderPaid).
data	Resource data: order, customer or subscription, depending on the event.

The request carries the User-Agent: apphook header.

Events

These are the same 28 events as the Webhooks tab, grouped the same way.

Orders

Event (event)	When it fires	data
OrderApproved	Order approved	order
OrderAuthorized	Order authorized	order
OrderAuthorizedWithDelay	Order authorized, sent 60 minutes later	order
OrderIntegrated	Order integrated	order
OrderPendingIntegration	Order pending integration	order
OrderPaid	Order paid	order
OrderRefund	Order refunded	order
OrderPartialRefund	Order partially refunded	order
OrderUpSold	Upsell paid	order
OrderRefusedByRisk	Order refused by antifraud	order

Payments

Event (event)	When it fires	data
OrderPixCreated	Pix generated	order
OrderPaidByPix	Pix paid	order
OrderPixExpired	Pix expired	order
OrderBilletCreated	Boleto generated	order
OrderBilletOverdue	Boleto overdue	order
PaymentNotAuthorized	Payment not authorized	order, with issuer_message
PaymentNotAuthorizedWithDelay	Payment not authorized, sent 60 minutes later	order, with issuer_message
OrderChargeBackInTreatment	Chargeback under review	order
OrderChargeBackGain	Chargeback won	order

Customers

Event (event)	When it fires	data
CustomerCreated	Customer created	customer
CustomerContacted	Customer contacted	customer
CustomerInterested	Interested customer, sent 60 minutes later	customer

Subscriptions

Event (event)	When it fires	data
SubscriptionDelayedEvent	Subscription overdue	customer, with subscription
SubscriptionCancellationEvent	Subscription canceled	customer, with subscription
CreatedSubscription	Subscription created	subscription lifecycle
CanceledSubscription	Subscription canceled	subscription lifecycle
ChargeSuccess	Subscription charge approved	subscription lifecycle
ChargeFailed	Subscription charge failed	subscription lifecycle

What comes in data

Order

Group	Fields
Identification	id, customer_id, status, origin, created_at, paid_at, refunded_at, integrated_at, upsell_order_id, invoice_id, payment_link_id
Amounts	total_products, freight_value, freight_type, discount, interest, total, full_payment_amount, total_refunded, refund_amount, cashback, partner_total, partner_affiliate_total
Payment	payment_type, installments, card_brand, card_details, issuer_message
Pix	pix_creation_date, pix_expiration_date, pix_emv, pix_ref, pix_qrcode, pix_end_to_end_id, pix_payment_link
Boleto	billet_url, billet_digitable_line, billet_date_overdue, order_billet_payment_code
Related	customer, bundles, products, visit, traffic_description
Company and commissions	company_name, company_cnpj, company_email, co_production_commission, affiliate_comission, seller_name

Fields that do not apply to the order come as null — the Pix ones on a card order, for example. issuer_message is only filled on the payment-not-authorized events.

Order data example (trimmed, fictitious data)

{
  "id": 99042,
  "customer_id": 17,
  "status": "aprovado",
  "payment_type": "CreditCard",
  "card_brand": "Visa",
  "installments": 12,
  "total_products": 242.03,
  "freight_value": 39.99,
  "freight_type": "PAC",
  "discount": 0,
  "interest": 57.97,
  "total": 339.99,
  "paid_at": "2026-10-01 15:02:52",
  "created_at": "2026-10-01 15:02:36",
  "origin": "API",
  "customer": {
    "id": 17,
    "firstname": "Maria",
    "lastname": "Silva",
    "email": "[email protected]",
    "document_number": "00000000000"
  },
  "bundles": [
    {
      "id": 23,
      "name": "Recipe book",
      "products": [{ "sku": "9000010", "name": "Recipe book", "price": "121.02", "quantity": 2 }]
    }
  ],
  "company_name": "My Store",
  "issuer_message": null
}

Customer

id, firstname, lastname, fullname, email, telephone, document_number, hash, address (postcode, address_street, address_street_number, address_street_complement, address_street_district, address_city, address_state, uf), site_id, created_at, interested_bundle (the product of interest, with a checkout link) and visited_url.

Subscription

• SubscriptionDelayedEvent and SubscriptionCancellationEvent: the customer fields plus a subscription object with id, installments, total, created_at, cancelled_at and the subscribed bundle (with its products).
• CreatedSubscription, CanceledSubscription, ChargeSuccess and ChargeFailed: the subscription lifecycle, with order_id and subscription_id. Depending on the event, they also carry interval and interval_count (on creation), uuid (on charges) and status.

Delays, retries and response time

• Sent right away, except for the three events marked with 60 minutes in the table, which only go out an hour after the fact.
• Reply with HTTP 2xx. Any other status, or a connection failure, counts as an error.
• Up to 4 attempts in total. After an error, Appmax waits 10 seconds, then 100, then 1,000 (about 17 minutes) before each new attempt. Once the attempts run out, the delivery is dropped.
• Reply fast. Put the event in a queue and return 200 before processing — a slow response can hit the timeout and turn into a new attempt.

Security

Deliveries are not signed: there is no signature header to validate. To avoid accepting forged calls:

• Use an HTTPS URL with a hard-to-guess path (for example, with a random token) and do not publish it.
• Before acting on a sensitive event — releasing a paid order, for example —, confirm through the API: fetch the order with GET /v1/orders/{order_id} using the received data.id.
• Ignore repeated events: store the event and data.id you already processed.

Testing the endpoint

In the webhook list of the Webhooks tab, the Test button sends the first event the webhook subscribes to, with fictitious data. Use it to check that the endpoint replies 2xx — not to check the values of a real order.

Delivery history, resend and conditional rules live on the full webhooks screen of the panel.