Connect an API endpoint

Do it

1. Test the endpoint in Postman first

   Before opening DashboardFox, confirm the API works. Paste your full URL into Postman, send the GET request, and look at the response. You're checking three things:

   • Does the request return 200 OK?
   • Is the response JSON?
   • Which key in the JSON holds your data array? (That's your response_path — for Google Sheets, it's values.)

   If anything fails here, fix it before going further. DashboardFox is just an HTTP client at this layer — if the URL doesn't work in Postman, it won't work in DashboardFox.

2. Create the API parent connection

   In DashboardFox, go to Settings → Integrations → Manage API → Create API.

   • Name — a friendly name. For multi-endpoint setups, this is the parent (e.g., Google Sheets); individual endpoints go under it. For a one-off, name it after the source (e.g., Sales Tracker Sheet).
   • Auth method — choose Manual for the API key path. (OAuth 2.0 is the other tab.)

   Save the parent. You're now ready to add endpoints.

3. Add the endpoint

   Inside your new API parent, click Add Endpoint.

   • Endpoint name — what this specific endpoint pulls (e.g., Sales Q4 Sheet).
   • URL — paste the full URL you tested in Postman, including the API key as a query parameter for Google Sheets.
   • Response path (response_by_name) — type the JSON key from your Postman response. For Google Sheets, this is values.
   • Headers — most public-with-key APIs need none. If your API requires headers (e.g., Authorization, X-API-Key), add them here.
   • Parameters — used for dynamic per-request parameters; not needed for the Google Sheets walkthrough. (Future lesson.)

   Save.

4. Connect — fetch the data and preview the tables

   From the endpoint's row, open the Action menu and click Connect. DashboardFox makes the HTTP request, parses the JSON, flattens it into one or more database tables, and stores them in its internal Postgres. Green check = success.

   Click Preview from the same Action menu. You'll see a list of tables DashboardFox created from your response — usually named API_2_2, API_2_3, etc. Click into each one to see its data. The "real" table — the one matching your response_path — is the one to remember; you'll point your reports at it.

   If the tables look wrong (no data, weird shape, the wrong subset of fields), the response_path is probably wrong. Fix it on the endpoint and Connect again. Manage API fetches covers the recovery flow with Purge & Connect.

5. Step B — create a Database app on top of internal Postgres

   Now the second half. The data lives in DashboardFox's internal Postgres database; you need a regular Database app on top of it for App Builder to read from.

   Open Settings → Integrations → DB Credentials tab. You'll see auto-filled connection details: host, database name, user, password. (These credentials only work from inside DashboardFox — they're not internet-accessible.) Note them down or keep this tab open.

   Switch to Active Integrations → Create App. Pick Database.

   • App Name — friendly name (e.g., Google Sheets Sales Data).
   • Database Driver — depends on your DBF version's internal DB; the DB Credentials tab tells you. PostgreSQL is the typical answer.
   • Host / Database / User / Password — paste from the DB Credentials tab.

   Click Test Connection, then Save & Apply.

6. Grant yourself access

   Saving the app doesn't grant access to it — not even to you. Connecting and granting access are deliberately separate steps; that's what stops a new data source from being accidentally exposed before you've decided who should see it.

   Go to Settings → Security → Apps, find your new app, click Edit, and assign yourself the App Builder role. Click Save & Apply.

   Refresh the page; the app appears in App Builder, ready for the semantic-layer work in Module 3. To grant other users: Composer for people who'll build reports on this data, Agent for people who'll just run them. The Roles & permissions lesson covers the model in depth.