In self service section, allow for the installtionId to be a computed value and not static value
A
AnilKumarReddy Gajulapalli
We’re using an INTEGRATION_ACTION with integrationProvider: "GITHUB" and would like to render installationId dynamically from the selected repository’s org_name:
"installationId": "{{ .inputs.repository.properties.org_name | ascii_downcase }}"
The template renders correctly in the payload preview, but the integration is never invoked (no GitHub workflow run, nothing in the GitHub integration logs). If we hard‑code installationId to "integrationIdentifier", it works.
sample:
"invocationMethod": {
"type": "INTEGRATION_ACTION",
"installationId": "{{ .inputs.repository.properties.org_name | ascii_downcase }}",
"integrationActionType": "dispatch_workflow",
"integrationActionExecutionProperties": {
"org": "{{ .inputs.repository.properties.org_name }}",
"repo": "{{ .inputs.repository.identifier }}",
"workflow": "run-create-vuln-issue.yml",
"workflowInputs": {
"trigger_user_id": "{{ .trigger.by.user.email | split(\"@\")[0] }}",
"base_branch": "{{ .inputs.base_branch }}",
"body": "{{ .inputs.body }}",
"title": "{{ .inputs.title }}"
},
"reportWorkflowStatus": true
}
}
We want to be able for this to work and to select the integration that is running the self service action
A
AnilKumarReddy Gajulapalli
While using a Classic Personal Access Token (PAT) with access to all GitHub orgs may appear to be a workaround for the static installationId limitation, in practice this introduces significant operational and architectural risks.
1) API Rate Limits Are Significantly Lower with PAT
Classic PAT: 5,000 requests per hour
GitHub App: 15,000 requests per hour (for GitHub Enterprise Cloud organizations)
When running integrations at scale (10s of GitHub orgs and 100s of repositories), this difference is substantial. A single large sync can easily exhaust the PAT limit.
2) Multi-Port Organizations Amplify the Problem
If multiple Port organizations are syncing against the same GitHub org(s):
One Ocean sync can consume most or all of the PAT quota.
Other integrations (or other Port orgs) will be throttled.
This creates unpredictable behavior and cascading failures.
3) Webhooks + 24h Resync Does Not Eliminate the Risk
We are already using GitHub webhooks to reduce API usage, which helps significantly.
However:
Port resyncs can only be scheduled up to every 24 hours.
When the full resync kicks in, the same rate-limit bottleneck reappears.
Large orgs with hundreds of repositories will consistently approach limits.
So this is not just a theoretical concern — it becomes a daily operational constraint.
4) PAT Rate Limits Impact Other Critical Systems
PAT limits are shared across all usage of that token within the organization.
In our case:
Jenkins pipelines fail when API limits are exceeded.
Other automation that relies on GitHub APIs becomes unstable.
The impact extends beyond Port.
This introduces cross-system coupling and failure propagation, which is undesirable in enterprise environments.
5) Static installationId Is a Scaling Blocker
We are provisioning Ocean integrations per GitHub organization (as intended with GitHub Apps).
However, because installationId must be static:
We cannot dynamically route the self-service action based on the selected repository.
We are forced to create one Self-Service action per GitHub integration.
This leads to configuration duplication.
It increases maintenance burden and drift risk.
It does not align with scalable multi-org design.
We were able to dynamically render repo and org, but installationId being static is currently a hard blocker.