Summary

The REST connector reaches APIs that answer a GET with one static header. Many business APIs need more: Notion and Search Console query with a POST body, Shopify and others speak GraphQL, Google and PayPal hand out short-lived tokens through OAuth2 or a service account, and GitHub-style APIs page through the Link header. Each full refresh also reloads every page, capped at 1,000 pages (apps/api/src/connectors.ts, REST branch of the import), so large histories cannot be imported at all.

Proposal

• Request: method (GET or POST), a JSON body template, and GraphQL as a body shape with a variables cursor.
• Headers: several static headers (for example an API version header next to the key), still stored encrypted.
• Login: OAuth2 client credentials and refresh-token flows, and Google service-account JSON, fetching the token server-side; secrets never reach the frontend.
• Paging: Link: rel="next" next to the existing next, cursor and offset modes.
• Incremental refresh: an optional cursor field (for example updated_at) stored per dataset, so a refresh asks only for newer records and merges them by key instead of reloading everything.

Questions

1. Is a more general REST connector the direction you want, or would you rather add named connectors per service, as with Stripe and PostHog?
2. Incremental refresh changes the snapshot model. Should a refresh then produce a new snapshot from the merged result, or is there a better fit with the versioned datasets?
3. Would you take this as one pull request or in steps (request and headers, login, paging, incremental)?

Status

We would like to contribute this. We use Helix Foundry as the interface on top of our company data and can implement and test it against real APIs once the direction is agreed.