How webhooks work

Tazki can notify your system when something happens in Tazki, instead of you polling the Public API. Each time a subscribed event occurs, Tazki sends an HTTP POST with a JSON body to a URL you provide.

Setup

• Each company has one webhook: one destination URL, the headers Tazki sends with every request and the events it receives.
• The Tazki team configures it for you. Send them:
  • the destination URL (https recommended),
  • the headers your endpoint needs to authenticate the request (for example Authorization: Bearer <token>),
  • the events you want to receive (see Events).
• Company admins can review the configuration and the delivery history in Tazki, under Configuración general → Integraciones → Webhooks (read-only). Header values and query string values are never shown there.

Events

Event	Sent when	Page
checklist.mandatory_document	A user completes a checklist that is mandatory for them in a work center	Mandatory documents
talk.mandatory_document	A user completes a mandatory talk	Mandatory documents
training.mandatory_document	A user completes a mandatory training	Mandatory documents
evaluation.mandatory_document	A user finishes a mandatory evaluation (passed or failed)	Mandatory documents
contractor_worker.accreditation	A contractor worker becomes accredited, or stops being accredited, in a work center	Contractor worker accreditation

The event name is always in the event field of the body, so one endpoint can receive all of them.

The request

POST https://your-system.example.com/tazki/webhooks
Content-Type: application/json
Authorization: Bearer <your token>

{
  "event": "contractor_worker.accreditation",
  "worker": {
    "user_id": 1001,
    "name": "Example Worker",
    "rut": "11.111.111-1",
    "email": "worker@example.com",
    "position": "Example Position",
    "contractor": { "name": "Example Contractor", "rut": "99.999.999-9" },
    "branch_id": 10,
    "branch": "Example Work Center"
  },
  "accreditation": {
    "status": "approved",
    "changed_at": "2026-11-05T10:12:00-03:00",
    "next_expiration": {
      "document": "Example Document",
      "owner": "worker",
      "contract": null,
      "expires_on": "2027-01-15"
    },
    "cause": null
  }
}

The body of each event is described in its page: Mandatory documents and Contractor worker accreditation. All names and ids in these examples are placeholders.

• Content-Type is always application/json.
• Every header configured for your company is sent on every request, exactly as configured.
• Tazki does not sign the body. Authenticate requests with the headers you configured, and use https so they travel encrypted.
• Dates and times are ISO 8601. Times include the offset (Chile time, for example 2026-11-05T10:12:00-03:00); dates without time look like 2027-01-15.

Responding

• Answer with any 2xx status to confirm you received the notice. The response body is ignored.
• Tazki waits up to 5 seconds to connect and 10 seconds for the answer. Store the notice and process it afterwards instead of doing the work before answering.
• Redirects (3xx) are not followed and count as a failed attempt.

Retries

When an attempt fails (any status other than 2xx, a timeout, or a connection or TLS error), Tazki retries it up to 3 more times, after about 15 seconds, 30 seconds and 1 minute. If every attempt fails, the notice is dropped and shows as failed in the delivery history. It is not sent again later.

Duplicates and order

• The same notice can arrive more than once, for example when your endpoint answered 2xx after Tazki had already given up waiting. Notices have no unique id, so make your processing idempotent using the fields of each event (each event page suggests which ones).
• Notices are not guaranteed to arrive in the order the changes happened. Use the dates in the body (completed_at, changed_at) to decide which one is the latest.