LINE × Kintone Integration

Operations staff needed real-time LINE notifications when kintone record statuses changed, and users needed a way to respond or acknowledge via LINE without accessing kintone directly. The existing workflow relied on manual notifications with no audit trail for confirmations.

The kintone customization layer runs in the browser, which means direct LINE API calls would expose tokens to the client. GCP Cloud Functions provided the webhook receiver endpoint that LINE's platform required — the challenge was making the two-way flow reliable under cold start conditions and noisy kintone webhook payloads.

• LINE API tokens must not be exposed in browser-side kintone customization code
• GCP Functions cold start latency could cause LINE signature verification to time out
• kintone webhooks fire on every field update — not just status changes that need notifications
• Reply API tokens expire after 30 seconds — incorrect use silently wastes the token

The architecture split into two halves: kintone customization scripts for outbound push notifications, and a GCP Cloud Functions endpoint for inbound LINE webhook handling. The key routing rule — Reply API only for immediate responses to user messages, Push API for all status change notifications — was enforced as a hard boundary in the codebase.

• kintone.proxy() wraps all LINE API calls from the customization layer — no tokens reach the browser
• Status change hooks filter at the kintone field level before triggering any API calls
• GCP Functions validates HMAC-SHA256 signature before parsing the event payload
• Flex Message templates use size tokens rather than raw px values for predictable mobile rendering

The most consequential architectural pattern was the Reply vs Push distinction. Reply API is cheaper and session-scoped — valid only for responding to a user's incoming message within 30 seconds. Push API is always-available but costs per message. Using Push for everything is expensive; using Reply for async status notifications causes silent failures.

• Reply API: only for direct responses to user postback events — immediate, within-session use only
• Push API: for all status change notifications and any outbound message not triggered by a user action
• Postback handlers in GCP Functions always use Reply — the reply token from the event payload is consumed once
• kintone status change hooks always use Push — they fire outside any user LINE session

Staff received real-time LINE push notifications on kintone record status changes with no manual intervention. Users could acknowledge or respond via LINE buttons, triggering postback events that GCP Functions handled and wrote back to kintone. The Reply vs Push boundary held — notification delivery was reliable and messaging costs stayed predictable.