Sync new users from Postgres to HubSpot

Keep your HubSpot CRM in lockstep with your application database. This blueprint watches a Postgres customers table for new and recently updated rows and pushes each one into HubSpot as a contact, so your sales and marketing teams always work from fresh data without manual CSV exports or brittle one off scripts. It closes the common gap between an operational database (where signups and profile edits actually happen) and the CRM (where revenue teams live), giving you a reliable Postgres to HubSpot pipeline that runs on its own.

How it works

1. A io.kestra.plugin.jdbc.postgresql.Trigger polls Postgres on a PT5M interval with fetchType: FETCH, selecting first_name, last_name, email, phone, and job_title from customers where updated_at is within the last day and the row has not yet been processed (processed_at IS NULL OR processed_at < updated_at).
2. The trigger exposes the result set as trigger.rows, and a io.kestra.plugin.core.flow.ForEach task iterates over every returned row.
3. For each row, a io.kestra.plugin.hubspot.contacts.Create task creates a contact in HubSpot, mapping email, firstName, lastName, phone, and jobTitle from the row values via json(taskrun.value).

What you get

• Hands off, near real time replication of customer records into HubSpot.
• Incremental syncing: only rows changed in the last day and not already processed are picked up.
• Clean field mapping from database columns to HubSpot contact properties.
• A declarative, version controllable pipeline instead of cron driven shell scripts.

Who it's for

• RevOps and marketing ops teams who need CRM data to match the source of truth.
• Data engineers wiring an operational Postgres database to downstream SaaS tools.
• Growth teams that want new signups in HubSpot the moment they land in the database.

Why orchestrate this with Kestra

Postgres can store and emit data, but it cannot orchestrate an end to end sync to an external API on its own. Kestra adds an event driven trigger that polls the table, fans out work with ForEach, and lets you attach retries, alerting, and error handling around the HubSpot calls. You get full execution lineage and logs for every contact created, a single declarative YAML definition you can review and version, and the ability to schedule or pause the pipeline centrally, none of which a database scheduler or an ad hoc script gives you.

Prerequisites

• A running Kestra instance with the Postgres (JDBC) and HubSpot plugins available.
• A Postgres customers table with first_name, last_name, email, phone, job_title, updated_at, and processed_at columns.
• A HubSpot account with API access for creating contacts.

Secrets

• HUBSPOT_API_KEY: HubSpot private app token or API key used to create contacts.
• POSTGRES_URL: JDBC connection URL for your Postgres database.
• POSTGRES_USERNAME: Postgres user with read access to the customers table.
• POSTGRES_PASSWORD: password for that Postgres user.

Quick start

1. Add the secrets above to your Kestra instance.
2. Confirm the customers table and its columns exist, or adjust the trigger SQL to match your schema.
3. Import this blueprint into your namespace.
4. Enable the flow and let the Postgres trigger poll; new or updated rows will appear as HubSpot contacts within five minutes.

How to extend

• Update processed_at after a successful create so the same row is not synced twice (add a follow up Query task).
• Switch from create to upsert logic to avoid duplicate contacts on repeated runs.
• Map additional HubSpot properties or enrich rows before sending.
• Add a notification task (Slack, email) on failure, and tune the trigger interval to your latency needs.

Links

• HubSpot plugin documentation
• Postgres plugin documentation
• Orchestrate Postgres with Kestra