Coder Legion - Recent posts tagged request

Retry Failed n8n API Requests Without Duplicates

Wed, 14 Oct 2026 15:50:00 +0000

The safe n8n retry pattern is simple: create one stable idempotency key for the business operation, send the same key and payload on every attempt, retry only temporary failures, and store the confirmed result. Turning on Retry On Fail without that protection can repeat a successful side effect when the first response was lost.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

The dangerous case: an API creates the order, but the connection closes before n8n receives the response. n8n sees a timeout. A second POST with a new key can create a second order even though the first request actually worked.

Decide whether the request is safe to repeat

HTTP defines GET, HEAD, OPTIONS, and TRACE as safe methods. PUT, DELETE, and the safe methods are idempotent by their intended semantics. POST is not automatically idempotent. The HTTP specification therefore says a client should not automatically retry a non-idempotent request unless it knows the operation is idempotent or can prove the first request was not applied.

Real APIs add their own rules, so the provider's documentation remains the contract. A DELETE endpoint may be harmless to repeat, while a POST that sends an email, creates a payment, or reserves stock needs explicit duplicate protection.

Failure	Default action	Duplicate risk
Network timeout or reset	Retry the identical request with the same operation key	High, because the remote service may already have committed the action
429 Too Many Requests	Wait for the provider's limit window, then retry	Controlled only if the operation remains idempotent
500, 502, 503, or 504	Use a small bounded retry policy when the provider permits it	Potentially high for state-changing requests
400, 401, 403, or most 404s	Fix the request, credentials, permission, or resource first	Blind retries add load but rarely fix the cause
409 Conflict	Inspect the API-specific error before deciding	May indicate an existing operation or key conflict

Step 1: create one key for one business operation

Build the key before the HTTP Request node from an ID that already belongs to the event: an order ID, checkout ID, lead ID, invoice ID, or source event ID. Include the action name so different operations on the same record cannot collide.

={{ 'create-order:' + $json.orderId }}

Keep this value unchanged across automatic node retries, manual execution retries, and later recovery runs. Do not use $now, the execution ID, or a freshly generated random value on each attempt. Those identify the attempt, not the operation, so the destination sees every retry as new work.

The key must also stay paired with the same endpoint and payload. If you correct the amount, recipient, or other business data, treat that as a deliberate new operation according to the provider's rules.

Step 2: use the API's idempotency feature first

If the destination API supports idempotency, send the stable key in the exact header or field its documentation specifies. Stripe, for example, accepts an Idempotency-Key header for POST requests and returns the stored result when the same request is repeated with the same key. That header name is not universal. Some APIs use a request ID, client reference, deduplication ID, or a provider-specific field.

Open the HTTP Request node and add the provider's documented idempotency header.
Map the stable operation key as its value.
Keep the method, URL, and request body identical on every retry.
Save the external object ID from the confirmed response for later reconciliation.

Do not assume: adding an Idempotency-Key header only works when the destination implements that contract. An unknown header may simply be ignored.

Step 3: configure a bounded n8n retry

Every n8n node has a Retry On Fail setting. When enabled, n8n reruns the node after a failure until it succeeds or reaches the configured attempt limit. For a known transient endpoint, start with a small policy such as three tries and a short wait between tries. Increase it only when the provider's limit and incident behavior justify the extra traffic.

This built-in setting is best when every error produced by that node is safe to retry. If you need status-aware behavior, enable Include Response Headers and Status and Never Error in the HTTP Request node. The node can then pass the status code and headers to an IF or Switch branch instead of stopping on every non-2xx response.

Send 2xx responses to the success branch.
Send 429 and approved temporary 5xx responses to a Wait step and bounded retry path.
Send authentication, validation, permission, and unexpected responses to a review or alert branch.
Stop after the maximum attempt count. Never create an unbounded loop.

Step 4: slow down 429 retries

A 429 response means the client sent too many requests in the provider's current limit window. Some APIs include Retry-After as seconds or an HTTP date. Read and honor it when the provider documents that behavior. If the header is absent, use the API's published limit and increase the delay between attempts rather than retrying immediately.

The HTTP Request node also has Items per Batch and Batch Interval options. They control how many input items are sent in each batch and how many milliseconds n8n waits between batches. Use them to prevent a known burst from creating the 429 in the first place.

Step 5: add a persistent duplicate check when needed

When the API has no idempotency feature, keep a small request ledger. n8n's Data Table node can check whether a row exists, insert rows, update them, and upsert by conditions. A practical table uses these columns:

Column	Purpose
`request_key`	Stable ID for the business operation
`status`	`pending`, `succeeded`, `failed`, or `unknown`
`external_id`	ID returned by the destination when available
`updated_at`	Timestamp for recovery and stale-pending review

Check for a row with the request key.
If it already says succeeded, return the stored result and skip the API call.
If no row exists, record pending, then call the API.
On a confirmed 2xx response, update the row to succeeded and store the external ID.
On a timeout, keep the state as unknown until you query the destination or retry safely.

This ledger is useful for sequential or low-concurrency workflows, but a check followed by an insert is not an atomic lock. Two executions can check at the same moment and both see no row. For parallel production traffic, prefer destination-side idempotency or a database table with a unique constraint on request_key and an atomic claim operation.

That pattern protects one API operation from replay. When the business problem is recognizing the same person across forms, email, phone, and an existing CRM, use the separate n8n lead deduplication workflow and its conflict-review path.

Do not use workflow static data as a production lock

The $getWorkflowStaticData() helper looks convenient for storing processed IDs, but n8n labels it experimental, says the data should be small, and warns that it may behave unreliably under high-frequency executions. That makes it unsuitable as the main duplicate barrier for valuable orders, payments, leads, or outbound messages.

A production-safe request sequence

Validate that the event contains a stable source ID.
Create the operation key once.
Check any local success record.
Send the request with the provider's idempotency mechanism.
Retry only network failures, 429s, and provider-approved temporary errors.
Reuse the same key and payload for every attempt.
Store the external ID after confirmed success.
Route exhausted or uncertain outcomes to an Error Workflow or manual review queue.

Keep request-level recovery separate from broad diagnosis. If you do not yet know why the node failed, use the failed n8n workflow debugging guide. Once the retry budget is exhausted, use an n8n Error Workflow to send the failure to Telegram, Slack, Google Chat, email, or another incident channel.

Common questions

Does Retry On Fail prevent duplicates in n8n?

No. It repeats the failed node. Duplicate prevention comes from idempotent request semantics, a provider-supported operation key, or a persistent store that can claim each business operation exactly once.

Should I retry every 500 response?

Not automatically. A 500 can leave a state-changing operation with an uncertain outcome. Follow the provider's error guidance, keep the same idempotency key, use a bounded retry policy, and reconcile the remote record when the result remains unknown.

Can the Remove Duplicates node replace an idempotency key?

It can remove repeated input items, but it cannot prove that a remote API did or did not apply an earlier request after a timeout. Protect the side effect at the API or persistence layer.

Sources checked

n8n partner link

Want managed n8n for the workflow?

I may earn a commission if you sign up through this link, at no extra cost to you.

Try n8n Cloud

Need one risky API workflow mapped?

Send the API operation, failure response, source ID, and expected business outcome. I will help separate safe retries from duplicate risk.

Map the retry path

Originally published on FloxoLab.

What is Runtime Identity? Securing Every Action Beyond Login

Sat, 25 Apr 2026 06:54:54 +0000

Runtime Identity is a security model that evaluates user identity during every action, not just at login. It moves identity verification from a one-time event to a continuous, context-aware process. Traditional authentication verifies who a user is only at login, then trusts all subsequent activity. This creates a gap where sessions, tokens, or APIs can be misused without re-evaluation.

Runtime Identity closes this gap by validating identity at request time using real-time signals. These signals include device context, user behavior, network conditions, and session risk. Instead of trusting a session blindly, every action is verified before it is allowed.

Runtime Identity applies across web apps, APIs, and AI agents acting on behalf of users. It ensures that identity is enforced consistently across all interactions, not just at entry points.

Runtime Identity secures every request, not just the login event.
Modern security requires continuous identity verification beyond authentication.

2. Quick TL;DR

Runtime Identity verifies user identity during every request, not just login.
Traditional authentication only validates identity once at session start.
Sessions and tokens can be misused after initial authentication.
Runtime Identity evaluates context like device, behavior, and network signals.
Every API call and user action can be validated in real time.
Risk-based decisions allow dynamic authentication and authorization.
Runtime Identity reduces token misuse and session hijacking risks.
It is critical for securing APIs, SaaS apps, and AI agents.
Continuous verification improves both security and control.
Modern systems require identity enforcement beyond login boundaries.

3. What is Runtime Identity

Runtime Identity is a security approach that evaluates user identity continuously during application usage. It ensures that every request, action, or API call is verified in real time.

Traditional systems establish identity once during login and trust the session afterward. Runtime Identity removes this blind trust and re-evaluates identity at runtime.

Runtime Identity shifts security from login-time to request-time verification.
It ensures identity is enforced across the entire user session lifecycle.

Key Characteristics of Runtime Identity

Continuous verification replaces one-time authentication.
Every request is evaluated before access is granted.
Identity decisions are based on real-time context signals.
Security adapts dynamically based on risk levels.
Applies across web apps, APIs, and backend services.

What Makes Runtime Identity Different

Authentication answers: Who is the user?
Authorization answers: What can the user access?
Runtime Identity answers: Should this action be allowed right now?

Runtime Identity adds a time and context dimension to identity.
It evaluates intent and risk at the moment of action.

Simple Example

User logs in from a trusted device → access granted
Same session performs unusual activity → re-evaluation triggered
High-risk action → additional verification required

Runtime Identity enables dynamic decisions based on real-time behavior.
4. Why Traditional Authentication Fails

Traditional authentication verifies identity only once at login. After that, systems trust the session or token without continuous validation. This creates a major security gap in modern applications.

Authentication is a point-in-time event, not a continuous process.
Trusting sessions blindly introduces significant security risks.

- Authentication is Point-in-Time

Authentication happens only during login. Once verified, the system assumes the user remains trusted for the entire session.

No re-validation during sensitive actions
No awareness of changing user behavior
No context-based decision-making

A user can become risky after login without detection.

- Sessions Are Blindly Trusted

After authentication, sessions or tokens are used for all subsequent requests. These sessions are treated as proof of identity without further checks.

Session hijacking goes undetected
Stolen tokens can be reused
No validation of session integrity

Session-based trust assumes identity does not change over time.

- Tokens Can Be Reused or Stolen

Modern systems rely heavily on tokens like JWTs. These tokens are valid until expiration and are often reused across multiple requests.

Tokens can be intercepted or leaked
No built-in mechanism to detect misuse
Long-lived tokens increase attack surface

Token validity does not guarantee user legitimacy at runtime.

- No Action-Level Verification

Traditional systems do not evaluate individual user actions. Once authenticated, users can perform actions without additional identity checks.

Sensitive operations are not re-evaluated
No step-up authentication for risky actions
No contextual awareness

All actions are treated equally regardless of risk.

- APIs Lack Identity Context

APIs typically validate tokens but do not evaluate context. They assume the request is valid if the token is valid.

No device validation
No behavior analysis
No risk scoring

API security is often limited to token validation only.

- Key Insight

Traditional authentication was designed for static systems. Modern applications are dynamic, distributed, and constantly changing.

Static authentication cannot secure dynamic systems.
Modern security requires continuous identity evaluation.

5. What Runtime Identity Actually Means

Runtime Identity means evaluating identity continuously at the moment of each request or action. It ensures that identity is not assumed but verified in real time using context and risk signals.

Runtime Identity evaluates identity at the exact moment of action.
It replaces static trust with dynamic, context-aware decisions.

Identity at Request Level

Every request made by a user or system is treated as a new verification point. Instead of trusting a session, the system evaluates whether the request should be allowed.

Each API call is validated independently
Context is checked for every interaction
Trust is recalculated continuously

Each request becomes a checkpoint for identity verification.

Identity at Action Level

Not all actions carry the same risk. Runtime Identity evaluates the sensitivity of each action and applies appropriate verification.

Low-risk actions → allowed seamlessly
Medium-risk actions → monitored
High-risk actions → require step-up authentication

Runtime Identity applies security proportional to action risk.

Continuous Verification

Runtime Identity continuously evaluates signals throughout the user journey. It does not rely on a single authentication event.

Identity is re-evaluated during the session
Changes in context trigger new decisions
Risk levels are updated dynamically

Identity is not static; it evolves during user interaction.

Context-Aware Identity

Runtime Identity uses context to determine whether a request is legitimate. Context provides additional signals beyond credentials.

Key Context Signals

Device type and fingerprint
User location and IP address
Time of access
User behavior patterns
Session history

Context transforms identity from static to adaptive.

Real-Time Decision Making

Runtime Identity systems make decisions instantly based on available signals. These decisions determine whether to allow, block, or challenge a request.

Allow → if risk is low
Challenge → if risk is medium
Block → if risk is high

Every decision is made in real time based on risk evaluation.

Simple Mental Model

Authentication → Entry gate
Authorization → Access control
Runtime Identity → Continuous security guard

Runtime Identity acts as a guard monitoring every action.
6. How Runtime Identity Works

Runtime Identity works by evaluating identity continuously during every request and action. It combines identity data, context signals, and risk analysis to make real-time decisions.

Runtime Identity evaluates every request instead of trusting the session.
Each action is verified using context-aware signals and risk scoring.

Step-by-Step Flow

1. User Authenticates

User logs in via SSO, passwordless, or passkey
Identity is established and verified
Session or token is issued

Authentication establishes initial identity but does not guarantee ongoing trust.

2. Session or Token is Created

System creates a session or issues a JWT
Token represents the authenticated identity
Session becomes the base for further interactions

Sessions represent identity but do not validate future actions.

3. Each Request is Intercepted

Every API call or action is intercepted
Runtime Identity engine evaluates the request
No request is blindly trusted

Every request becomes a verification checkpoint.

4. Context Signals Are Collected

Device information
IP address and location
Time and frequency of requests
Behavioral patterns

Context provides additional signals beyond credentials.

5. Risk is Evaluated

System assigns a risk score to the request
Based on anomaly detection and policy rules
Compares current behavior with baseline

Risk scoring determines whether a request is safe or suspicious.

6. Policy Engine Makes Decision

Allow → if risk is low
Challenge → if risk is medium
Block → if risk is high

Policy decisions are based on real-time evaluation.

7. Action is Enforced

Request is executed or denied
Step-up authentication may be triggered
Logs are recorded for auditing

Security decisions are enforced instantly at runtime.

Key Components in the Flow

Identity Layer → Who is the user
Context Engine → What is happening now
Risk Engine → Is this behavior normal
Policy Engine → What should be done

Runtime Identity combines identity, context, and policy into one decision system.

Real Example

User logs in from India → normal behavior
Same session tries access from another country → anomaly detected
System triggers MFA or blocks request

Runtime Identity detects and responds to changes instantly.

7. Runtime Identity vs Authentication vs Authorization

Authentication, authorization, and runtime identity serve different purposes in a security system. They operate at different stages and answer different questions.

Authentication verifies identity, authorization grants access, and runtime identity validates actions continuously.
All three are required for modern, secure systems.

Core Differences

Factor	Authentication	Authorization	Runtime Identity
Purpose	Verify user identity	Control access permissions	Validate actions in real time
Timing	At login	After authentication	During every request
Scope	Identity only	Resources and permissions	Identity + context + behavior
Decision Model	Static	Rule-based	Dynamic and risk-based
Security Level	Basic	Moderate	Advanced
Use Case	Login systems	Access control	Continuous security

Authentication

Authentication answers the question: Who is the user?

Happens once at login
Uses credentials like password, OTP, or passkeys
Establishes initial trust

Authentication is the entry point of identity verification.

Authorization

Authorization answers the question: What can the user access?

Based on roles and permissions
Determines access to resources
Does not validate ongoing behavior

Authorization controls access but does not validate intent.

Runtime Identity

Runtime Identity answers the question: Should this action be allowed right now?

Evaluates each request dynamically
Uses context and risk signals
Adapts decisions in real time

Runtime Identity validates intent and behavior continuously.

Simple Analogy

Authentication → Entry gate
Authorization → Access badge
Runtime Identity → Security guard monitoring every move

Runtime Identity ensures actions remain safe after access is granted.

Key Limitations Without Runtime Identity

Authentication cannot detect post-login risk
Authorization cannot adapt to real-time behavior
Sessions can be misused without detection

Authentication and authorization alone are not sufficient for modern security.

8. Core Components of Runtime Identity

Runtime Identity is built from multiple interconnected components that work together to evaluate identity continuously. Each component plays a specific role in collecting signals, assessing risk, and enforcing decisions.

Runtime Identity is a system of components, not a single feature.
Each component contributes to real-time identity evaluation.

1. Identity Layer

The identity layer establishes and maintains the user’s identity. It connects authentication data with runtime evaluation.

Stores user identity and session details
Links tokens, sessions, and user context
Provides base identity for all requests

Identity layer answers who the user is.

2. Context Engine

The context engine collects real-time signals from each request. It provides additional data beyond identity credentials.

Context Signals Include:

Device type and fingerprint
IP address and geolocation
Time and frequency of requests
Browser and OS details

Context engine answers what is happening right now.

3. Risk Engine

The risk engine evaluates whether a request is normal or suspicious. It compares current behavior with historical patterns.

Assigns risk scores
Detects anomalies
Identifies unusua