Currently only self-hosted Atlassian Confluence is supported. However Atlassian Cloud is widely adopted and has a nearly identical API endpoint structure.
Currently Gerev suggests creating a PAT in order for the system to authenticate and pull data. That PAT is then used as a bearer token to the upstream Atlassian API. For Cloud installations, account-specific API tokens are allowed, which are used as basic auth where the username is the account holder's email address, and the password is the generated API key.
From there, the same endpoint structure and payloads are used to scrape the /space endpoint
Issue
Currently only self-hosted Atlassian Confluence is supported. However Atlassian Cloud is widely adopted and has a nearly identical API endpoint structure.
Currently Gerev suggests creating a PAT in order for the system to authenticate and pull data. That PAT is then used as a bearer token to the upstream Atlassian API. For Cloud installations, account-specific API tokens are allowed, which are used as basic auth where the username is the account holder's email address, and the password is the generated API key.
From there, the same endpoint structure and payloads are used to scrape the
/space
endpointAPI Tokens are managed here
Further Questions
How do we distinguish auth types? It doesn't make sense to duplicate the entire data source logic just to support a different auth scheme.