Integrations

Scitor runs on GitHub, which means GitHub Actions is your built-in integration layer. Any service with an HTTP endpoint can receive Scitor ticket events — no native connector needed, and nothing extra to pay for.

When an email or form submission arrives, Scitor creates a GitHub Issue and applies structured labels: spam:clean, category:bug-report, sentiment:negative, priority:urgent, and others. GitHub Actions workflows fire on those label events and can call any external API from there.

Slack

Yes, Scitor integrates with Slack. You can send a Slack message whenever a new support ticket arrives, when an SLA is breaching, or only when specific conditions are met (for example, a frustrated customer reporting a bug).

A basic new-ticket feed in Slack takes about 15 lines of YAML. Each message includes the ticket category, sentiment (green / amber / red), and a direct link to the GitHub Issue. If you want to limit notifications to urgent situations only, you can filter on priority:urgent or sentiment:negative instead.

See the Slack examples in the GitHub Actions guide for ready-to-copy workflows.

Microsoft Teams

Yes, Scitor integrates with Microsoft Teams. The setup uses a Teams Incoming Webhook and is structurally identical to the Slack integration — configure the webhook URL as a repository secret, and the workflow posts a colour-coded card to your chosen channel when new tickets arrive.

Cards are colour-coded by sentiment: green for positive, amber for neutral, red for negative, so your team gets an at-a-glance signal without opening the ticket.

See the Teams example in the GitHub Actions guide.

Linear

Yes, Scitor integrates with Linear. When Scitor labels a ticket category:bug-report, a GitHub Actions workflow can call the Linear GraphQL API to create a corresponding issue in your engineering team’s backlog. The Linear issue URL is posted back to the support ticket so both sides stay linked.

This means a customer bug report and the internal engineering task are connected from the moment the email arrives — no manual copy-pasting between tools.

See the Linear example in the GitHub Actions guide.

PagerDuty

Yes, Scitor integrates with PagerDuty. A workflow on the priority:urgent label triggers a PagerDuty incident via the Events API. A critical customer issue that arrives out of hours becomes an on-call alert rather than a ticket discovered the next morning.

The workflow uses a stable dedup key (the issue number) to prevent duplicate incidents if the label is removed and reapplied.

See the PagerDuty example in the GitHub Actions guide.

Zapier

Yes, Scitor integrates with Zapier. Use the generic webhook workflow to POST ticket data to a Zapier Catch Hook — Zapier then routes it to any of the 6,000+ apps in their catalog. This gives you a bridge to HubSpot, Salesforce, Notion, Google Sheets, Airtable, or anything else Zapier supports, without writing custom code for each one.

See the webhook example in the GitHub Actions guide.

Make (formerly Integromat)

Yes, Scitor integrates with Make. The same outbound webhook pattern works with Make’s incoming webhook trigger. Build a Make scenario that receives the ticket payload and routes it into any of Make’s modules.

See the webhook example in the GitHub Actions guide.

Jira

Yes, Scitor integrates with Jira. Use the Jira REST API from a GitHub Actions workflow to create a Jira issue when a specific type of ticket arrives. The pattern is the same as the Linear example: call the API on a label event, create the issue, and post the Jira link back to the GitHub Issue.

Any other service

If a service has an HTTP endpoint, Scitor can send data to it. The outbound webhook workflow POSTs a JSON payload with the ticket number, title, URL, category, sentiment, and priority. From there, you decide what to do with it.

See the webhook example in the GitHub Actions guide for the full payload format.

How to set up an integration

1. Find the workflow example for the service you want in the GitHub Actions guide.
2. Copy the YAML file into .github/workflows/ in your Scitor-connected repository.
3. Add the required secret (webhook URL, API key, etc.) under Settings → Secrets and variables → Actions in your repository.
4. Push and commit — the workflow is live immediately.

No dashboard to configure. No plan to upgrade. The integration is a file in your repository, version-controlled alongside everything else.

Creating tickets from your own systems

Everything above sends ticket data out of Scitor. The reverse — one of your systems opening a ticket — works too, but there is no separate Scitor ticket API to learn: a Scitor ticket is a GitHub Issue or Discussion, so you create one with the GitHub REST API, the GraphQL API, or the gh CLI against your Scitor-connected repository.

The only thing Scitor needs from you is a small metadata comment in the issue body that records who the ticket is from.

Create the issue

With the gh CLI:

gh issue create \
  --repo your-org/your-support-repo \
  --title "Card reader offline at store 42" \
  --body-file ticket.md

Or with the REST API:

curl -X POST https://api.github.com/repos/your-org/your-support-repo/issues \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  -d @ticket.json

Use a token that can create issues in the repository — a fine-grained personal access token with Issues: read and write, or a GitHub App installation token.

The sender metadata comment

For your team to be able to reply to the customer with /send, the issue body must contain a hidden HTML comment identifying the sender:

<!-- probot = {"from":"customer@example.com","fromName":"Jane Doe"} -->

A complete body looks like this:

> **From:** **Jane Doe** (`customer@example.com`)

The card reader at store 42 has been offline since 09:00 this morning.
Restarting it did not help.

<!-- probot = {"from":"customer@example.com","fromName":"Jane Doe"} -->

The blockquote header is only for readability — Scitor reads the comment, not the header. The comment is invisible in GitHub’s rendered view.

Supported fields:

Rules the parser enforces:

• The comment may appear anywhere in the body — top or bottom, both work.
• The value must be flat JSON. A nested object or array-of-objects breaks parsing, and Scitor falls back to “no sender”.
• cc entries must be bare addresses (cc@example.com), not Name <cc@example.com>.
• Put the customer’s real address in from. That address is what receives the reply.

Replying works normally

Once the metadata comment is in place, an API-created ticket behaves like an emailed one. /send emails the customer from your support address, and the Reply-To it sets routes their answer back onto that same issue as a comment. No extra wiring needed.

What an API-created ticket does not get

Some bookkeeping only happens on the email and web form paths, because it needs information that only those channels supply:

Sending email on a customer’s behalf

If you would rather keep using email as the entry point and relay messages for your customers, note that Scitor reads the From header only. Reply-To is used by mail clients, but Scitor does not treat it as the sender — a relayed message with your system in From and the customer in Reply-To produces a ticket attributed to your system, and /send replies to your system rather than the customer.

Putting the customer’s address in From gives the right attribution, but sending as a domain you do not control usually fails SPF and DMARC checks at the receiving end. Such messages still arrive, labelled spam:high by spam detection, which is not a good basis for a production integration.