External Notifications

What is it and what is it for?

An External Notification is the configuration of an automatic alert: you choose an Object (for example, Credit Invoices or Items), an Event (After Create, Edit, Delete, Void, Authorize, Reject or Update Stock), and a destination URL. From then on, every time that event happens on that document type in your company, AdmCloud sends a background POST request with a JSON body to that URL, without stopping or slowing down the transaction that triggered it.

It's mainly used to integrate AdmCloud with other systems in near real time: for example, notifying your external warehouse system when an invoice is created, updating your own dashboard when an item's stock changes, or triggering a flow in an automation tool (Zapier, Make, your own endpoint, etc.) when a cash receipt is recorded or a document is voided. For now the only available notification type is Webhook; the Type field is meant to scale to other channels (email, SMS, etc.) in the future.

Screens in this area

How to create an external notification step by step

1. Open the list and click New. You need the "add" level of the "External Notifications" permission.
2. Choose the Object you want to monitor, from the catalog of documents that support external notifications (see the list below). Type is fixed to Webhook, the only one available for now.
3. Enter a descriptive Name that helps you identify the notification in the list (for example, "Notify warehouse when invoice is created").
4. Choose the Event that should trigger it: After Create, Edit, Delete, Void, Authorize, Reject or Update Stock. The two authorization ones only apply to objects with an approval flow, and Update Stock only to Items.
5. Enter the URL of the external system that will receive the notification. It must be a complete, valid URL (including its protocol, e.g. https://...).
6. Enter the Secret (optional, at least 16 characters) if you want deliveries to be signed so the receiving system can verify the notification came from AdmCloud. It has to be the same value you configure on the other side. Leave it empty and calls are sent unsigned.
7. Choose the Owner (the user responsible for the configuration) and, if you want only that person to view or edit this notification, check Protected.
8. Make sure it's Enabled and add notes if you need to leave context for other users.
9. Save. From then on, every time the chosen event happens on the chosen object, AdmCloud will call the URL in the background.

Objects that support external notifications

Today you can create external notifications on these documents and catalogs:

• Purchases: Expense Reports, Purchase Orders, Vendor Bills, Vendor Credit Notes, Vendor Debit Notes, Vendor Receptions, Vendor Tax Withholdings.
• Sales: Quotes, Sales Orders, Cash Invoices, Credit Invoices, Cash Receipts, Cash Returns, Customer Credit Notes, Customer Debit Notes.
• CRM: Opportunities, Prospects.
• Inventory: Items, Services, Remission Guides.
• Relationships: Customers, Vendors, Employees.
• Banking: Vendor Payments.
• Customer Service: Service Requests, Work Orders.

If you pick an object that isn't on this list, AdmCloud rejects the save and tells you that object doesn't support External Notifications.

Key capabilities

• Near real-time notification: the webhook call runs in the background right after saving, so the user doesn't have to wait or notice any difference when recording their document.
• JSON body with the event, the object and the record's identifier (or several identifiers, for the Update Stock event), so your external system knows exactly what changed and can look up the details if it needs to.
• Multiple notifications per object/event: you can register more than one URL for the same object and event if you need to notify different systems.
• Turn on/off without deleting: uncheck Enabled to temporarily pause a notification without losing its configuration.
• Owner-protected configuration: if you flag a notification as Protected, only its owner (or an AdmCloud support user) can view or edit it.
• Signed delivery: if you set a Secret, every call carries an X-AdmCloud-Signature header with the HMAC-SHA256 signature of the body, so your system can verify the request came from AdmCloud and that nobody altered the content in transit. With no secret set, the call is sent unsigned.
• Automatic retries: if your system doesn't respond or returns a server error (status 500 or above), AdmCloud retries up to 3 times, waiting 1 and 2 seconds. A client-side rejection (status 400 to 499) is not retried, since repeating it would give the same result.
• Delivery log: AdmCloud stores every delivery (successful or not) with the body it sent, the response it got back and how many attempts it made. If a notification never arrived, AdmCloud support can check that log and tell you exactly what your system replied.

Key fields

Validations when saving

• Object is required, and must be one of the objects that support External Notifications; if you pick another one, AdmCloud tells you and won't let you save.
• Name is required.
• Type is required (fixed to Webhook).
• URL is required, and must be a valid absolute URL (including its protocol, e.g. https://...); if the format is wrong, saving is blocked.
• Owner is required.
• Secret of at least 16 characters, if you choose to set one (it's optional). A short secret can be guessed, and then the signature stops being a guarantee. Leading and trailing spaces are stripped, because a space picked up while copying would break verification on your side without leaving any clue.
• Duplicates aren't allowed: the same combination of Object, Event and URL can't exist on two different notifications.

Availability, plan and activation

• This feature requires a plan with API access, available from the Basic plan up (Basic, Standard, Premium, Premium Plus and its variants, Enterprise). It's not available on the Billing or Start plans.
• Besides the plan, your account needs to have External Notifications enabled. If your plan includes it but you don't see this screen or its permission in User Groups, contact AdmCloud support to have it activated.
• Access to the screen is controlled by the "External Notifications" permission of the user group, with separate levels for browsing, adding, editing and deleting.

Payload that gets sent (JSON format)

Every call is a POST with a Content-Type: application/json header and a compact JSON body (no indentation), with properties in PascalCase exactly as they're declared internally in AdmCloud. This is not the same format (camelCase/lowercase) used by the REST API responses described in the Web API Guide; if your integration already consumes the API, don't assume the webhook body follows the same naming convention.

Regular events (Create, Edit, Delete, Void, Authorize, Reject)

{
  "EventID": 0,
  "EventName": "After Create",
  "ObjectID": 40030,
  "ObjectName": "Credit Invoices",
  "RecordID": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}

RecordID is the identifier (GUID) of the record that triggered the event: the same value you'd use to look up the full document through the AdmCloud API. The webhook payload does not include the document itself (lines, totals, customer, etc.), only the bare minimum to identify what changed; if you need the detail, your system has to fetch it using that RecordID.

The "After Update Stock" event

This event has a different shape: instead of RecordID it carries RecordIDs, a list, because a single transaction (a reception, a bin transfer, an inventory adjustment, a production build, etc.) can affect several items' stock at once. ObjectID is always Items, no matter which transaction triggered the stock change.

{
  "EventID": 3,
  "EventName": "After Update Stock",
  "ObjectID": 130060,
  "ObjectName": "Items",
  "RecordIDs": [
    "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "a1b2c3d4-1234-4a1b-9c3d-4e5f6a7b8c9d"
  ]
}

EventID codes

ObjectID codes

ObjectID is the internal numeric code AdmCloud uses to identify each document type; it's the same catalog used across the whole application, not something exclusive to External Notifications. These are the codes for the objects that currently support external notifications:

Headers and signature verification

• Content-Type: application/json on every delivery.
• X-AdmCloud-Signature: only sent when the notification has a Secret configured. With no Secret, the header simply isn't sent (it doesn't arrive empty or with an invalid signature).
• Timeout: AdmCloud waits up to 30 seconds for your system's response on each attempt. If you don't respond in time, it's treated the same as a network failure (see Automatic retries below).

To verify a notification genuinely came from AdmCloud and wasn't altered in transit:

1. Compute HMAC-SHA256 over the raw UTF-8 bytes of the body exactly as you received it (the raw text of the POST request), using the same Secret you entered when configuring the notification. Don't re-serialize the JSON yourself before signing it: reordering properties or changing whitespace changes the result, and the signature won't match even though the content is "the same".
2. Convert the HMAC result to lowercase hexadecimal.
3. Compare that value against the X-AdmCloud-Signature header with the sha256= prefix stripped (for example, sha256=f7bc83f4...).

Tips and common pitfalls