Webhook

In this section, you will find information about how the Webhook of the Unico IDCloud platform works

---

The respective GetProcess articles for integration methods describe a way to obtain the status of a process through a call to an endpoint. This allows for polling to receive information about created processes, meaning the endpoint can be called multiple times for the same process to obtain the most recent status.

With the use of webhooks, it's possible to notify a specific endpoint every time the status of a process changes.

What is a Webhook?​

---

A webhook is a notification service that enables asynchronous integration between systems, where one system notifies another through a trigger. This allows webhooks to keep systems updated with the latest information without the need for constant polling for updates.

How to Configure the Webhook

---

To configure the webhook, the following information is required:

• Notification URL: This is the endpoint used by By Unico for notifications about status updates.

• Authentication Type: This is the authentication method used to invoke the endpoint. The following options are available:

  • Basic Authorization

  • API Key

  • No authentication

• Secret: This indicates a secret used for authentication. The secret is only necessary when the authentication type is Basic Authorization or API Key:

  • For Basic Authentication, it must be sent in the format user:pass.

  • For API Key, it can be sent in two formats:

    • header:value, when a specific header name is desired;

    • value, when the desired header is the Authorization.

• Retry Settings: Indicates the number of attempts in case of a failure in calling the endpoint:

  • Maximum number of attempts

  • Interval between attempts (in seconds)

• Rate Limit: Maximum number of simultaneous sends (maximum: 500).

• Timeout: Maximum wait time for the endpoint's response (in seconds).

• Status to be Notified: Currently, the notification is sent whenever the state of a process changes to:

by Unico	by Client
finished: Process finished.	2: In divergence; 3: Completed; 4: Canceled; 5: Error.

Sobre a autenticação:

The API can be protected by an authentication method such as Basic Authentication or API Key. A list of valid IPs for access can also be defined for additional protection.

Integration with the Unico IDCloud Platform

---

By configuring a webhook on the platform, you can receive information about processes through notifications sent to an API endpoint developed by you to receive these updates.

The information sent by the platform to the API includes:

by Unico	by Client
processId: ID of the transaction; state: State of the transaction; flow: Journey of the transaction.	id: ID of the transaction; status: State of the transaction;

Requests​

---

The request should be a POST method in a REST API, making it easier and safer to send information. All fields must be mandatory. The body of the request should accept the transaction ID and the state, as shown in the following example:

by Unico

{
  "processId": "8263a268-5388-492a-bca2-28e1ff4a69f0",
  "state": "PROCESS_STATE_FINISHED",
  "flow": "id"
}

by Client

{
  "id": "8263a268-5388-492a-bca2-28e1ff4a69f0",
  "status": 3
}

About response status:

Currently, the platform has a set of statuses that may vary in the future. Therefore, it is recommended that the statuses of interest for taking action be configurable.

Response

---

The response must come synchronously. The status for successful requests should be in the range of 200 to 299. Any other status is considered a failure, and the platform will retry notifications (with exponential backoff between them) until receiving a 2xx response or until reaching the maximum number of attempts.

Rate limit

To avoid overloading your resources during high transaction volumes, it is possible to specify a maximum limit on how many times the endpoint can be invoked.

Error rate

The error rate (responses outside the range of [200, 299]) should always be low. Otherwise, the throughput of the webhook will be automatically reduced, and this reduction along with the retry mechanism may lead to an increase in the execution time of new webhooks.

Idempotency

The current webhook implementation guarantees at-least-once delivery, meaning the same status can be notified more than once. Therefore, the implementation of the endpoint should be done in an idempotent manner.

Fallback

In case of any unavailability of the webhook service, it is recommended to have a fallback method in place so that you can continue to obtain the status of transactions within the established response time. The query to the endpoint is described in the GetProcess sections corresponding to each integration method.

---

Still need help?​

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.