HTTP credential tasks
Fix the endpoint, constrain parameters and select output fields.
On this page
Workflow
Choose an authentication method for the HTTP resource, then fix the method and URL in the task. Declare ordinary parameters separately; the broker fills credential slots internally. Connection testing sends only HEAD and does not silently make a business request.
Boundary and checks
Select only necessary JSON Pointer fields; without selected fields only status is returned. HTTPS validates certificates and hostnames, and redirects are not followed. For POST and other writes, the idempotency key deduplicates locally; it does not guarantee exactly-once remote execution.
Fixed endpoint and authentication
Save an HTTP resource with no authentication, Bearer, Basic or an API-key header. Use HTTPS for authenticated business services. Connection testing sends HEAD only, so a server that rejects HEAD may still support its business API. A task fixes the method and exact URL; credentials, query strings and fragments do not belong in that URL. Configure query fields separately. GET, HEAD, POST, PUT, PATCH and DELETE are available; redirects are not followed.
Request and minimal result
Configure fixed text, ordinary parameters and credential slots separately. Ordinary values may enter headers, query fields or a top-level JSON object; secrets are inserted internally into allowed headers or JSON fields and are not returned to the AI. Select necessary response fields with JSON Pointers such as /data/version. With no selected fields, only status is collected. Response bodies are limited to 256 KiB; missing fields or invalid JSON fail explicitly.
At approval, check method, target, all parameters, authentication placement, accepted status codes and output fields. Results are filtered before storage; filtering known secrets does not identify every sensitive business value. HTTPS validates certificate and hostname. Put a private CA in trusted system configuration instead of bypassing verification.
Writes and failures
The same approval and idempotency key reuse a local run; they do not guarantee exactly-once execution by the remote service. After a timeout, cancellation or disconnect on POST, PUT, PATCH or DELETE, inspect the target before requesting another run. Connection errors, invalid JSON, missing fields and oversized responses return stable error codes rather than server error bodies.
Corresponding product documentation · Report a documentation issue