Skip to content

API Connector (REST and cURL)

Use API Connector when Wappler should call an external API on the server, import cURL, and control auth or secrets safely.

Use API Connector when the API call belongs on the server

API Connector is the better fit when Wappler should call an external API from Server Connect instead of exposing the request details to the browser. That is especially useful when authentication, secrets, rate limits, data normalization, or chained backend logic make a server-side boundary the safer design.

Server-owned auth
Keep API keys and secrets on the server side.
Importable requests
Bring in existing cURL examples instead of rebuilding them from scratch.
Reusable output
Return normalized JSON to any page or workflow that needs it.
Choose API Connector when the request should not be assembled in the browser.
Import a cURL example when the provider documents the API that way.
Return only the shape your page or downstream action actually needs.

A practical first workflow is import cURL, test the request, then shape the output

The most reliable beginner pattern is to start from a working request example, import or rebuild it in API Connector, test the response, and then decide what the rest of your app should consume. That keeps the integration focused on the contract instead of burying it inside page logic.

Start from a real API request example instead of guessing the request shape.
Test the response before wiring it into the rest of the app.
Normalize or reduce the response when your page does not need the full provider payload.

The key checks are auth, request shape, and failure visibility

When API Connector integrations fail, the usual causes are wrong credentials, headers or query/body fields that do not match the provider contract, and error handling that hides the useful part of the failure. Make those three checks routine.

Auth first
Confirm keys, tokens, or signed headers before debugging the rest.
Request fidelity
Headers, params, method, and body must match the provider example.
Visible failures
Keep the error response visible long enough to debug it properly.

Next steps

Use the related tours below when you want the full action surface or adjacent debugging patterns.