create-connector-document

Goal

Generate the public-facing documentation for the {{source_name}} connector, targeted at end users.

Output Contract

Produce a Markdown file strictly following the standard template at templates/community_connector_doc_template.md as src/databricks/labs/community_connector/sources/{{source_name}}/README.md.

Documentation Requirements

• Please use the code implementation as the source of truth.

• Use the source API documentation to cover anything missing.

• Always include a section about how to configure the parameters needed to connect to the source system.

• If the connector_spec.yaml declares a connection.oauth block, document the connection as OAuth-based: the user registers an OAuth app in the source and supplies its client_id + client_secret (not a token); the connection obtains the token automatically. Cover how to create the OAuth app in the source and which scopes to grant. Describe the user experience, not the internal flow name — do not mention m2m / u2m / u2m_per_user in end-user docs (users don't configure those; the flow is fixed by the spec). Let the spec's flow decide only what you describe:

  • client-credentials: the connection authenticates machine-to-machine — no browser login, no redirect URI to register.
  • interactive: creating the connection opens a browser for the user to sign in and authorize, so the OAuth-app setup section MUST document the Authorized redirect URIs to register, covering both ways a connection can be created:
    • Databricks UI flow (from the "Add Data" page): the provider redirects back to Databricks, so the user must add https://<your-workspace-url>/login/oauth/http.html (substituting their own workspace URL). Omitting this causes a redirect_uri_mismatch error in the consent popup.
    • community-connector CLI flow: the CLI listens on a local loopback, so registering the loopback host (e.g. http://localhost, which covers the http://127.0.0.1:<port>/callback the CLI picks at runtime) is sufficient — no workspace URL is involved.

  See the Gmail connector README for the reference pattern. (Only surface a flow choice if the connector genuinely supports more than one and the user must pick.)

• AVOID mentioning internal implementation terms such as function or argument names from the LakeflowConnect.