Skip to main content
HTTP Request

Connecting External APIs (HTTP)

How to connect external APIs to your agent with secure authentication. Bearer auth, Basic auth, timeouts, x402 payments, and limitations explained.

Written By Philippe

Last updated 3 days ago

Connecting External APIs

✅ Supported — Custom implementation with known limitations (see below)

| Auth | None, Bearer, Basic, or Predefined Credential Type via Secure Vault |

Compatibility

FeatureStatus
GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONSSupported
JSON, Form-Urlencoded, Raw bodySupported
Bearer and Basic auth (via Secure Vault)Supported
Pagination (offset-based, next-URL)Supported
Batching (parallel execution)Supported
Retry on 429/5xxSupported via the node's Retry On Fail setting (off by default)
ContinueOnFailSupported
x402 payment protocolSupported (automatic — see below)
OAuth2 via Predefined Credential Type (Slack, Google, Microsoft, etc.)Supported — credentials are managed by Secure Vault and refreshed automatically
Generic OAuth2 (under Generic Credential Type)Not supported — use a Predefined Credential Type for OAuth2 services
Digest authNot supported — use Bearer or Basic instead
ProxyNot supported — platform constraint
SSL/TLS client certificatesNot supported — platform managed TLS only
Streaming responseNot supported — full response in memory
Binary filesIn-memory only — base64, ~50MB limit
Header AuthNot supported — blocked at deploy. Use a Predefined Credential Type instead (see below)
Query AuthNot supported — blocked at deploy. Use a Predefined Credential Type instead (see below)
Default timeout300 seconds, like n8n. An explicit Timeout option wins
Body on GET/HEADConverted to query parameters
Follow Redirects offSupported — the node returns the redirect answer and does not follow it, as in n8n
Repeated parameter namesPartial — two query or form parameters with the same name send only the last value. n8n sends both. A query string you write in the URL itself, such as ?ids=1&ids=2, is sent as written
Pagination expressionsSimplified — $response.body.*, $response.headers.*, $pageCount + arithmetic only

Header Auth and Query Auth

"Header Auth" and "Query Auth" under Generic Credential Type are not supported and will be rejected when you deploy your agent. These credential types let you enter a custom header or query parameter name, but the platform cannot honor that name due to its security architecture (API keys are stored externally and injected by the proxy with fixed names).

Use Predefined Credential Type instead. Select the credential that matches your API — each one has the correct authentication header already configured. For example, to call the Gemini REST API, select "Google Gemini" as the Predefined Credential Type.

Bearer Auth and Basic Auth under Generic Credential Type are supported — use them when your API is not in the predefined list.

How to set up Bearer Auth:

  1. In the HTTP Request node, set Authentication → "Generic Credential Type" → "Bearer Auth"
  2. When you connect the credential, enter your Bearer token and the Allowed Domains — the hosts this token may be sent to (e.g. api.myservice.com)
  3. The platform stores the token in the Secure Vault and injects Authorization: Bearer <token> on every request to an allowed host

How to set up Basic Auth:

  1. In the HTTP Request node, set Authentication → "Generic Credential Type" → "Basic Auth"
  2. When you connect the credential, enter your username, password, and the Allowed Domains
  3. The platform encodes them and injects Authorization: Basic <base64> on every request to an allowed host

Allowed Domains is required. It is a comma-separated list of host names, with *.example.com for sub-domains — the same setting the credential has in n8n. *.example.com covers sub-domains only, not example.com itself — list both when the workflow calls both. The request goes to the URL the node names; a host that is not on the list fails with Domain not allowed. When the node URLs are fixed, the form offers their hosts so you only confirm. A credential used only to protect your own Webhook or MCP Trigger needs no list.

If no predefined credential exists for your API, let us know and we'll add it.

Automatic x402 Payments

When your HTTP Request node calls an API that uses the x402 payment protocol, indie.money handles payment automatically. You don't need to configure anything — it just works.

How it works:

  1. Your agent calls an x402-enabled API
  2. The API responds with a payment request (HTTP 402)
  3. indie.money automatically pays the requested amount from your agent's wallet
  4. The request is retried with proof of payment
  5. You receive the API response as normal

What gets charged:

  • The payment amount is deducted from your agent's wallet balance
  • Your prepaid balance (0% fee) and USDC are both supported — prepaid balance is preferred automatically
  • The cost appears in your execution history alongside any other API costs

When it applies:

  • Calling external x402-enabled APIs (AI services, data providers, other indie.money agents)
  • Calling other indie.money agents via their webhook URL
  • Any HTTP endpoint that returns an x402 payment challenge

Budget protection:

  • Your agent's wallet balance is checked before paying — if the balance is insufficient, the node returns an error instead of paying
  • The API cost ceiling you set for your agent still applies — x402 costs count toward the ceiling
  • Each payment is tracked and visible in your execution details

Example: An AI agent agent that calls an external x402 language model API:

Webhook trigger → Process input → HTTP Request (x402 API) → Format output                                       ↑                                  Payment handled                                  automatically

No payment code needed in your agent. The platform handles the payment negotiation transparently.

Status

This integration is available but has not yet been independently validated on indie.money. If you encounter issues, please report them.