website logo
Sign upLogin
⌘K
πŸ€—Welcome
πŸš€Engineering success
🧭Alignment
⚑Delivery
πŸ’—Health
🏷️Categorizing work
Dimensions
Initiatives
Teams
🎯Measuring success
Defining targets
Delivery performance
πŸ”ŒData connections
Data sources
Data exports
API authentication
πŸ””Automated reports
Email report
Slack reports
πŸŽ“Reference
πŸ‘€Administration
πŸ“…Changelog
2023
2022
Docs powered byΒ archbeeΒ 
2min

GitLab API proxy

GitLab api permissions scope are all or nothing: you can only grant access to the entirety of the API surface. This may prove problematic for the most security-conscious customers, most notably because the API includes file-related endpoints.

Proxying the GitLab API

We have created the GitLab API proxy to give our users the ability to use Echoes together with GitLab while benefiting from stronger security guarantees. It can proxy API calls to a self-hosted GitLab instance or to the cloud hosted gitlab.com with the following added benefits:

  • The proxy limits the set of exposed endpoints to the strict subset required by Echoes.
  • The proxy uses its own authentication token so that you don't have to trust us to securely hold your GitLab token.
  • The proxy is preconfigured to allow connections from Echoes HQ exit IPs.

A note about GitLab webhooks

While the proxy limits how Echoes can consume the GitLab API, it is worth noting that Echoes still installs group-level hooks and subscribes to webhook events. Therefore, while inbound API requests are proxied, outbound webhook events are emitted directly from your GitLab instance toward our infrastructure. You can review the content of these events in the GitLab documentation.

ο»Ώ

Updated 03 Mar 2023
Did this page help you?
Yes
No
UP NEXT
Issue trackers
Docs powered byΒ archbeeΒ 
TABLE OF CONTENTS
Proxying the GitLab API
A note about GitLab webhooks