Use HuggingFace Inference API to classify customer message

Triage incoming customer messages automatically with zero-shot text classification. This blueprint reads a customer message from a Postgres database, sends it to the HuggingFace Inference API using the facebook/bart-large-mnli model, and writes the predicted category back to the same row. It solves the problem of manually routing support, warranty, upsell, and help requests by turning free-text messages into structured labels your downstream systems can act on, no model training or hosting required.

How it works

1. The flow takes a message_id input identifying the customer message to classify.
2. The retrieve_data task (io.kestra.plugin.jdbc.postgresql.Query) runs a SELECT against customer.message with fetchType: FETCH_ONE to fetch the user_id and message text.
3. The classification task (io.kestra.plugin.huggingface.Inference) sends the message to the facebook/bart-large-mnli model with candidate_labels of support, warranty, upsell, and help for zero-shot classification.
4. The insert_category task (io.kestra.plugin.jdbc.postgresql.Query) runs an UPDATE that writes the top predicted label (labels[0]) back to the category column for that message_id.
5. Postgres connection settings are set on both query tasks.

What you get

• Automated, consistent labeling of free-text customer messages.
• Predicted categories persisted directly in your Postgres database.
• A reusable pattern for zero-shot classification with no custom model to train.
• A clean separation between data retrieval, inference, and write-back.

Who it's for

• Support and operations teams that need to route or tag inbound messages.
• Data engineers building AI-assisted enrichment pipelines.
• Developers who want HuggingFace inference wired into a real database workflow.

Why orchestrate this with Kestra

Kestra coordinates the database reads, the inference call, and the write-back as one declarative YAML flow with built-in retries, full execution logs, and lineage across tasks. You can drive it from event triggers (for example, a new row in Postgres or a webhook) rather than polling, something the HuggingFace Inference API and a raw database cannot orchestrate on their own. Secrets, parameters, and connection settings stay centralized instead of scattered across scripts.

Prerequisites

• A running Kestra instance.
• A Postgres database with a customer.message table containing message_id, user_id, message, and category columns.
• A HuggingFace account with Inference API access.

Secrets

• HUGGINGFACE_API_KEY: HuggingFace Inference API token.
• POSTGRES_HOST: Postgres host for the JDBC connection.
• POSTGRES_USERNAME: Postgres username.
• POSTGRES_PASSWORD: Postgres password.

Quick start

1. Add the four secrets above to your Kestra instance.
2. Confirm your customer.message table schema matches the queries.
3. Add this blueprint to a namespace.
4. Execute it with a valid message_id.
5. Check the category column to confirm the predicted label was written.

How to extend

• Swap candidate_labels to match your own taxonomy.
• Point model at a different HuggingFace model for your task or language.
• Persist the full label and score set instead of only the top label.
• Add an event trigger so each new message is classified automatically.
• Branch on the predicted category to route messages to different teams.

Links

• HuggingFace plugin docs: https://kestra.io/plugins/plugin-huggingface
• JDBC Postgres plugin docs: https://kestra.io/plugins/plugin-jdbc-postgres