GitHub features

Setup

• Install the Issued GitHub App on any repos you want to route support to. This grants the permissions needed to create issues and post comments.
• When you create a project, pick a repo from your installed accounts. You can't change the repo later — create a new project instead.
• The webhook that lets Issued see new comments is provisioned automatically. No manual setup.

Pre-setting labels and assignees

Attach hidden fields to your embed to apply GitHub labels, assignees, or a milestone automatically. Handy for routing bugs vs. feature requests to different assignees from the same embed.

fields: {
  subject:     { visible: true, required: true },
  description: { visible: true, required: true },

  // Comma-separated. Labels are case-sensitive GitHub label names.
  github_labels: {
    visible: false,
    value: "bug,customer-reported"
  },

  // Comma-separated GitHub usernames. Must have write access to the repo.
  github_assignees: {
    visible: false,
    value: "johndoe,support-team"
  },

  // GitHub milestone number.
  github_milestone: {
    visible: false,
    value: "5"
  }
}

Full field reference in the fields guide.

Comment author filter

Issue comments flow back to the submitter as emails — but not every comment should. Configure allow / block lists of GitHub usernames in your project settings.

• Allow list — if set, only comments authored by these usernames become emails.
• Block list — comments authored by these usernames never become emails.
• Usernames are matched without the leading @.

For one-off private comments, prefix with (ignore) — see the email replies guide.

Allowlisting

GitHub-backed projects use the same domain allowlist and bundle-ID allowlist as Linear projects. The provider is independent of where the submission originates from — configure allowlists based on your web / mobile deployment, not your issue tracker.