Help Center

English

Português
Español

English

Português
Español

Appearance

Webhooks ​

Introduction ​

Webhook reverses the communication flow and allows systems to communicate much more easilyandefficient** in response to events. Routers may sometimes take time to respond to a request under some conditions, such as:

  • Device off (will respond when initiated)
  • Incorrect Force Connection URL or password
  • Actions like reboot or reset, which take time to occur
WebHooks will only work if they are previously activated inClientes API.

Operation ​

Upon receiving a request registered in WebHooks, the API will respond with a receipt confirmation message, with a protocol number that identifies all actions related to the request.

Protocol number

The protocol number is a 32-character UUID, with groups separated by hyphens. All replies sent through WebHooks and derived from a request will have the same UUID. Supported Methods Supported methods indicate that WebHook will be used to notify the result of an action initiated by IXC/Application Client:

  • **devices/parameters/update/😗*Notifies the status of the parameter update.
  • **/api/v1/devices/reboot:**Notifies whether the reboot command (reboot) has been successfully executed or failed on the device. Webhook operation To illustrate the operation of WebHook in the context of supported methods (Update and Reboot), the scenario is set to show the notification of the result of a remote action rather than just the connection drop. Scenario 1: Using a Webhook - Result Notification In this model, the Server (API) notifies the Client API/IXC ACS about the result of a previously requested action as soon as the device completes it.
  1. Requested Action: The IXC ACS sends a request to the API requesting the Reboot of the RTR-42 Router.
  2. Configuration: The IXC ACS has already informed the API of its Webhook URL for completion notifications (e.g.https://monitoramento.ixc.com/resultado).
  3. The RTR-42 Router completes reboot**(or failure occurs) at 10:07:00**.
  4. Action: The API instantly** sends a requestPOSTto the Webhook URL with payload detailing the result (e.g.{"protocolo": "UUID-DO-REBOOT", "router_id": "RTR-42", "status": "success", "timestamp": "10:07:00"}).
  5. Result: The IXC ACS receives notification In real time, updating the status of the command on dashboards and continuing with the workflow.

Main advantage: The requesting system (IXC ACS) does not have to wait or ask, it is warned as soon as the action that may take time is completedorfail**. Scenario 2: Using Traditional API (Polling) - Result Check In this model, the IXC ACS would need to actively check the status of the command in the router.

  1. Requested Action: The IXC ACS sends the request of Reboot to the API at 10:05:00.
  2. Configuration: IXC ACS is configured to, for example, every 5 minutes**, ask the API about the status of the command.
  3. The Router concludes the reboot at 10:07:00**.
  4. Action: -**10:05:00:**Reboot command sent.

  • 10:07:00: Reboot completed. The IXC ACS does not know that.

  • 10:10:00: The IXC ACS makes the first polling request for the API: "The X command has been completed?" (Receives the status of success).

  1. Result: The status of the command is only updated in IXC ACS at 10:10:00h, resulting in a 3-minute delay** between the completion of the action and the system update. Main advantage: The requesting system is waiting** (or checking) for an indefinite time, and the status update depends on the polling range.
In case of timeout (1 hour), an error WebHook will be sent, but the action can still be executed on the device.

Glossary ​

Timeout

Final considerations ​

It is essential to activate WebHooks correctly and follow security practices in the configuration. Understanding supported methods and protocol numbers contributes to efficient integration, especially when dealing with actions that may take time, such as reboot and update parameters.

Read it too ​