Sentry (self-hosted) | Operate As Docs

Connect your client's Sentry (self-hosted) with a key they paste, and call its API through Operate As.

Website: sentry.io
Connects by: Pasting a Auth token
Category: Developer tools
Services: 1
Tools: 252

Service	Key	Base URL
Sentry (self-hosted)	`sentry-self-hosted`	`https://{site}/api/0`

Your client also types their sentry address (Where your Sentry is, such as example.com, without https://).

Connecting

Your client makes a Auth token in their Sentry (self-hosted) settings and pastes it on their link. Operate As tries it with Sentry (self-hosted) before saving it, and stores it encrypted. See Services connected with an API key.

Check they're connected

curl https://api.operate.as/v1/me/clients \
  -H "Authorization: Bearer $OPERATE_AS_API_KEY"

curl https://api.operate.as/v1/me/clients \  -H "Authorization: Bearer $OPERATE_AS_API_KEY"

Response

[
  {
    "id": "6f1c2a7e-...",
    "name": "Miller Dental",
    "services": [
      "sentry-self-hosted"
    ]
  }
]

[  {    "id": "6f1c2a7e-...",    "name": "Miller Dental",    "services": [      "sentry-self-hosted"    ]  }]

Permissions

What the client reads	Permission it asks for
Use the Sentry (self-hosted) key you paste, with only the access you gave that key	Chosen on the provider's screen

Tools

Install Sentry (self-hosted)'s typed package for your language:

pip install operate-as-sentry-self-hosted

pip install operate-as-sentry-self-hosted

Run sentry-self-hosted.add_organization_member

curl -X POST https://api.operate.as/v1/actions/sentry-self-hosted.add_organization_member \
  -H "Authorization: Bearer $OPERATE_AS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "clientId": "6f1c2a7e-...",
    "input": {
      "organization_id_or_slug": "<organization_id_or_slug>"
    }
  }'

curl -X POST https://api.operate.as/v1/actions/sentry-self-hosted.add_organization_member \  -H "Authorization: Bearer $OPERATE_AS_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "clientId": "6f1c2a7e-...",    "input": {      "organization_id_or_slug": "<organization_id_or_slug>"    }  }'

Shows the required inputs. Every input, with its JSON Schema: GET /v1/actions/sentry-self-hosted.add_organization_member

Response

{
  "status": 200,
  "data": {
    "…": "the service's own response"
  },
  "encoding": "json"
}

{  "status": 200,  "data": {    "…": "the service's own response"  },  "encoding": "json"}

Pass-through

Paths continue from https://{site}/api/0, with the parts in braces filled in from your client's account. Your Operate As key goes in Authorization; the client's access is added for you.

See Pass-through requests for the full request and response format.

Call any endpoint

curl "https://api.operate.as/v1/clients/6f1c2a7e-.../sentry-self-hosted/..." \
  -H "Authorization: Bearer $OPERATE_AS_API_KEY"

curl "https://api.operate.as/v1/clients/6f1c2a7e-.../sentry-self-hosted/..." \  -H "Authorization: Bearer $OPERATE_AS_API_KEY"

Response

{
  "status": 200,
  "data": {
    "…": "the service's own response"
  },
  "encoding": "json"
}

{  "status": 200,  "data": {    "…": "the service's own response"  },  "encoding": "json"}

When access ends

A key works until your client deletes it in Sentry (self-hosted). They can paste a new one on the same link at any time, and your workflows carry on without changes.

See Keeping access alive and Removing access.

Calls answer, once the key is deleted

{
  "status": 401,
  "data": {
    "…": "the service's own error"
  },
  "encoding": "json"
}

{  "status": 401,  "data": {    "…": "the service's own error"  },  "encoding": "json"}