If you run a scheduled price alert in Pipedream, moving the HTTP request is only part of the job. The new workflow also needs the same schedule, market-hours rule and memory of the last accepted price. Otherwise, the first run can look like a new crossing, or two workflows can send the same alert.
Pipedream says Workflows and String will close on March 31, 2027, with Workflows data deleted by April 30, 2027. Pipedream Connect is unaffected. These dates come from its shutdown notice, checked on October 2, 2026.
This guide uses our existing AAPL level-crossing workflow for n8n. It checks market status, samples AAPL and sends Slack a message when a newer accepted price changes sides around a chosen level. Start with that one alert, then move other workflows separately.
1. Save the old workflow and its operating settings#
In Pipedream, open your project's Settings, choose Export Workflows, then download the ZIP from File Store. The export requires a plan with File Stores. Inspect manifest.json for skipped workflows and warnings.
The archive contains workflow structure, not a working n8n import. Credentials, environment variables, event history and data-store contents are excluded. Save any state you need separately and reconnect accounts in n8n. See Pipedream's export documentation for the full scope.
For the alert you are moving, record the following in a private handover note. Account names are enough; do not put secret values in the note.
| Record from the old alert | Why it matters during the move |
|---|---|
| Symbol, source and threshold | A different feed or level can produce different alerts even when the workflow is correct. |
| Schedule and explicit timezone | The same clock time can mean a different market session after migration. |
| Session rule | Decide whether the alert operates during regular hours, extended hours or all day. |
| Trigger rule | “Price is above 200” and “price moved from below 200 to above 200” produce different notification patterns. |
| Latest accepted timestamp and side of the level | This is the comparison baseline. It is separate from the most recent message sent. |
| Slack destination and alert owner | Someone needs to distinguish a quiet market from a workflow that stopped running. |
| Retry and duplicate handling | Check what can happen after a failed send before assuming the new behavior matches. |
Keep the existing alert running while you configure the replacement. Leave the new workflow's production notifications off until its behavior is checked.
2. Import the existing n8n example#
Open the AAPL workflow article, save its workflow JSON and use Import from File in n8n. Import the JSON from that article, not the Pipedream export. n8n documents its import options here.
Create an n8n Header Auth credential with its Name field set to X-API-Key and its Value field set to your SiftingIO key. Select that credential in both HTTP Request nodes. Connect Slack and choose a test channel. The example uses built-in n8n nodes, so it does not require the SiftingIO community node.
Start with AAPL and the example configuration. Its level of 200 is a demonstration value, not a current price or a recommended alert level. Follow the original article when changing it: the request, detector settings and market gate must describe the same instrument.
The existing scripts have offline fixture checks. An actual n8n import, scheduled execution and Slack delivery have not been verified for this guide. Test them in your installed version before switching the alert people rely on.
3. Match behavior before matching the screen#
The example runs every five minutes from 13:00 through 21:55 UTC on weekdays. Each run checks US equities market status; only an open result proceeds to the price request. Keep the workflow timezone explicitly set to UTC. The Schedule Trigger uses the workflow timezone, falling back to instance settings when none is set.
Compare these rules with your old alert:
| Existing AAPL example | Migration decision |
|---|---|
| Alerts on a change from one side of the level to the other | If your Pipedream job sends repeated above-threshold reminders, this is a change in behavior. Decide which one you want. |
| Checks timestamps and accepts only newer samples | Do not replace the data timestamp with the time the workflow ran. |
| Rejects samples more than 60 seconds old | Check that this is suitable for your data access and alert purpose. |
| Stops before the price request when the market gate reports closed | Match the session policy before extending the schedule. |
| Records a rate-limit result without automatically retrying the price request | Do not assume Pipedream retry settings transferred. Check failures and usage in the new environment. |
A sampled alert can miss a crossing that reverses between polls. Changing platforms does not remove that limitation.
4. Treat the baseline as a separate migration step#
Importing this example does not transfer Pipedream's saved alert state. The first valid sample away from the level establishes a new baseline and sends no crossing alert. A sample exactly at the level waits for a side to be established.
For example, a fresh detector receiving 199.50 first establishes “below 200.” A later accepted sample of 200.01 produces an upward crossing. Starting it for the first time at 200.01 only establishes “above 200.” These are illustrative values, not observed prices.
Keep the threshold fixed while testing that sequence. Editing the level resets the detector's comparison state, so changing it between runs is not a crossing test.
The example stores its baseline in node-scoped workflow static data. n8n describes this storage as experimental and saves changes after successful triggered executions; manual test runs do not establish persistence. Verify the baseline across scheduled runs, not just clicks on the test button. See n8n's static-data documentation.
If preserving every notification across the handover is a requirement, pause the migration here. This example does not include a state importer, durable message queue or a guarantee of delivery without duplicates or gaps.
5. Rehearse, then switch one production sender#
Run the replacement against your test channel while the old alert remains responsible for production notifications. Check a scheduled baseline, a later same-side sample, the controlled crossing test and a closed-market run. Inspect node output as well as Slack: no message alone does not prove that a run succeeded.
Once those checks pass:
- Record the last successful Pipedream run and the latest successful n8n run, including their accepted data timestamps.
- Pause the old alert's trigger and allow any in-flight run to finish.
- Switch the tested n8n workflow to the intended Slack destination and confirm its schedule is published or active in your version.
- Inspect its next scheduled execution. Confirm the expected market decision and detector output, even if no crossing occurs.
- Keep the old workflow available for rollback, with its trigger paused. If you roll back, pause n8n first and review the old baseline before re-enabling it.
The two workflows will not necessarily sample at the same instant, so do not expect identical message timestamps. During the rehearsal, both also consume API requests. Include that overlap when checking your usage allowance.
Open the existing AAPL workflow and setup guide to start with one alert. Keep the old configuration until the replacement's scheduled runs and notifications have been checked.
