Keep your data current, without copying it.
Fetch data from an API, prepare the fields you need and update PostgreSQL in a scheduled workflow.
For teams in data, integration and operations.
The day-to-day need.
Your business application exposes data through an API, but reporting still relies on manual exports. Formats differ and every update involves the same repetitive steps.
- Manual exports create a gap between the business catalog and the reporting database.
- A poorly formatted reference or price can break matching between systems.
- When something fails, the final file cannot show whether the API, preparation or database write caused it.
Example: a product catalog for reporting
Every morning, fetch products from your business application. Normalize references and prices, then update the table used by your internal reporting.
- Without a workflow
- Someone downloads the catalog, fixes its columns and imports the file into the database on every update.
- With nodulz
- A schedule starts the same retrieval, normalization and writing sequence; each step can be inspected separately.
How nodulz solves the problem.
nodulz connects the source and the database while keeping the transformation visible. The team defines a data contract, then assembles the nodes that implement it.
A predictable starting point
The Schedule node sets the cadence. The HTTP request specifies the endpoint, authentication and parameters used to fetch the catalog; you can change the source without rewriting the rest.
Fields aligned with your database
The Fields node prepares the references, names and prices PostgreSQL expects. Expressions use data from earlier steps, making each mapping explicit.
A controlled database write
The PostgreSQL query applies your insert or update rule. A unique key and matching strategy are defined in the database to avoid recreating a product on the next run.
From trigger to outcome.
Schedule · HTTP request · Fields · PostgreSQL
The catalog follows a readable path into PostgreSQL. Editor capture of an illustrative workflow that has not been executed.
Scroll the capture horizontally to follow the full workflow.
What happens at each step.
- 1
Every morning
Set the retrieval time to match how often your source changes.
- Data used
- Reporting time and timezone, for example 09:00, Europe/Paris.
- What the step passes on
- A new run starting the catalog retrieval.
- 2
Fetch products
Call the catalog API with its parameters and authentication.
- Data used
- API URL, credentials and retrieval parameters.
- What the step passes on
- Product references and attributes returned by the API.
- 3
Normalize
Select and rename fields to match your target table format.
- Data used
- Raw product reference, name and price data.
- What the step passes on
- Fields expected by the target table, such as sku, label and unit_price.
- 4
Update database
Write a parameterized query to insert or update products by reference.
- Data used
- Normalized fields and matching rule by reference.
- What the step passes on
- SQL query result; the product table can then be used for reporting.
Example workflow: adapt connections, parameters and rules to your environment. The data shown is illustrative.
What this workflow brings.
Retrieval and preparation follow the same path on every run. Your team can inspect incoming data and identify the step that needs attention.
- A shared format between the source and reporting.
- Regular retrieval without a manual export.
- Diagnosis by step rather than a search through the final file.
Keep control of the process.
The matching key and SQL query remain explicit. Plan for API pagination and a database uniqueness constraint to adapt this scenario to your volume.
Explore available nodes