KUFU · AsyncAPI Specification
Kufu Smarthr Webhooks
Version
View Spec
View on GitHub
CompanyHuman ResourcesHR TechPayrollEmployee DataSaaSJapanOnboardingSocial InsuranceWebhooksAsyncAPIWebhooksEvents
AsyncAPI Specification
generated: '2026-07-19'
method: searched
source: >-
https://developer.smarthr.jp/api/about_webhook, cross-checked against the
Webhook definition in openapi/kufu-smarthr-openapi.json
type: Webhooks
description: >-
SmartHR's event surface. SmartHR publishes NO AsyncAPI description, so this
is a faithful catalog of the documented webhook contract rather than a
generated spec — nothing here is invented. Webhooks are the only push channel
SmartHR offers; there is no streaming, SSE, or message-broker surface.
asyncapi_published: false
delivery: HTTP POST, JSON body
registration:
ui: SmartHR admin dashboard, "External System Integration" section
api: true
operations:
- getV1Webhooks
- postV1Webhooks
- getV1WebhooksId
- putV1WebhooksId
- patchV1WebhooksId
- deleteV1WebhooksId
fields:
url: Destination endpoint receiving the POST. Required.
event: >-
Which events to subscribe to. On the API resource these are individual
boolean flags (crew_created, crew_updated, ...), each defaulting to
required.
secret_token: >-
Optional shared secret, echoed back on delivery in the X-SmartHR-Token
request header.
description: Optional free-text note.
expose_only_id: >-
When true, deliver only the id of the changed record instead of the full
object.
access_type:
enum: [read_and_update, hidden, read_and_update_only_origin]
security:
mechanism: shared secret in a request header
header: X-SmartHR-Token
signature_verification: false
note: >-
SmartHR echoes the configured secret token verbatim in X-SmartHR-Token. It
does NOT compute an HMAC signature over the payload, so a consumer can only
verify the sender knows the secret — it cannot verify payload integrity or
replay-protect a delivery. Consumers should terminate TLS themselves,
compare the token in constant time, and treat the payload as untrusted
until re-read from the API.
envelope:
fields:
event:
type: string
description: The event id (see events[] below).
triggered_at:
type: string
format: ISO 8601
description: When the event fired.
sender:
type: object
nullable: true
description: The Crew object that caused the change, or null.
payload:
description: >-
One event-specific key carrying the subject — one of crew,
crew_import_result, dependent, dependent_import_result, or workflow.
events:
- id: crew_created
trigger: Employee record created.
payload_key: crew
payload_object: Crew
- id: crew_updated
trigger: Employee record modified.
payload_key: crew
payload_object: Crew
note: >-
For future-effective changes this fires on the effective date, not when
the change was booked.
- id: crew_deleted
trigger: Employee record fully removed.
payload_key: crew
payload_object: Crew
- id: crew_imported
trigger: Batch employee import completed.
payload_key: crew_import_result
payload_object: CrewImportResult
- id: dependent_created
trigger: Family/dependent record created.
payload_key: dependent
payload_object: Dependent
- id: dependent_updated
trigger: Family/dependent record modified.
payload_key: dependent
payload_object: Dependent
- id: dependent_deleted
trigger: Family/dependent record removed.
payload_key: dependent
payload_object: Dependent
- id: dependent_imported
trigger: Batch family import completed.
payload_key: dependent_import_result
payload_object: DependentImportResult
- id: workflow_approved
trigger: A workflow reached its final approval step.
payload_key: workflow
payload_object: Workflow
note: Fires immediately on approval, regardless of effective dating.
delivery_semantics:
success_criteria: A 2xx HTTP response returned within 60 seconds.
timeout_seconds: 60
retries:
production:
attempts: ~17
window: ~3 days
sandbox:
attempts: ~5
window: ~8 minutes
on_exhaustion: The webhook registration is disabled.
ordering: not guaranteed / not documented
deduplication: not documented
suppression:
parameter: skip_sending_webhook=true
description: >-
Append to an API write request to suppress webhook delivery for that
operation. The standard guard against infinite loops when a webhook
consumer writes back into SmartHR.
payload_state_semantics: >-
Payloads always reflect the employee's state at send time, even when the
underlying change carries a future effective date. Consumers that need the
booked-versus-effective distinction must re-read the record through the API.
related:
conventions: conventions/kufu-conventions.yml
openapi: openapi/kufu-smarthr-openapi.json
docs: https://developer.smarthr.jp/api/about_webhook