REST API (Write)

Push rows to an HTTP API, one record per request or many batched into one.

Category

Output

Connection

REST API

Also known as

http, api, post, push, web service, endpoint, bulk, reverse etl, webhook, load

What it does

Rows go TO the API and nothing comes back. It sends the incoming rows to an endpoint (through a saved REST API Connection) in whichever shape that API accepts: one record per request (with ${column} in the path, so PUT customers/${id} addresses each record), or many records batched into one JSON array, optionally wrapped under a key. A rate limit (429), a 503 or a connection that never opened is retried; a request that may already have reached the API (a timeout after sending, a dropped connection, any other 5xx) is never sent again, because a resent write is a duplicate. The run stops and names the request instead, so you can check the API before re-running. Which of the three REST nodes do you want? • REST API (Read): rows come FROM the API; one fixed request, then pagination. • API Lookup: rows come from somewhere else and the API ADDS A COLUMN to each one. • REST API (Write): rows go TO the API and nothing comes back.

Inputs and outputs

When to use it

• Load records into a SaaS or internal API that has no database
• Push a nightly batch to a partner's bulk endpoint
• Update records one by one by their id
• Send each row to a SOAP service, or to an API that takes form fields (Stripe, Twilio)

Examples

Method: POST · Body: one record per request

Body: one record per request · Written as: Form fields

Body: one record per request · Written as: XML · <Order id="${id}">${name}</Order>

Body: many per request · rows per request: 100 · wrap under: records

Method: PUT · path: customers/${id}

Tips

• One record per request is the default because it is the COMPATIBLE shape: most REST APIs have no bulk endpoint and answer 400 to a JSON array. Switch to batches only where the API documents one; then 200,000 rows are 2,000 requests instead of 200,000.
• Updating by id (PUT customers/${id}) is always one record per request: the id is in the URL, so there is no way to address 100 records at once unless the vendor built a bulk endpoint.
• Need the response back, such as a created id or a status? This node discards it. Use API Lookup, in the Lookup tab.
• HTTP has no transaction: a failure partway leaves the rows already accepted in place.
• Empty columns are left out by default, from JSON and from form fields; most APIs prefer that to an explicit null.
• XML and form fields send one record per request; a batch is always a JSON array. In form fields each column becomes one field named after it, so rename columns upstream for names like metadata[order_id].
• “If a request fails: continue” keeps the run going and reports the skipped count in Messages.
• Batched requests can't use ${column}: there's no single row to read it from.
• Writing to Salesforce? Use the Salesforce node instead. That endpoint answers HTTP 200 even when every record failed, so this node would report a clean run having written nothing.

Related nodes