You want customer emails to automatically appear as GitHub Issues. No manual copying, no Zapier chains, no custom webhook servers. Just emails in, issues out.
Here is how to set it up with Scitor in under five minutes. Actual five minutes, not marketing five minutes.
What you need before starting
- A GitHub account with at least one repository where you want to receive support issues.
- Access to your email provider’s forwarding settings (Gmail, Google Workspace, Fastmail, or any provider that supports email forwarding).
- That is it. No server, no API keys, no credit card.
Step 1: Install the Scitor GitHub App (1 minute)
Go to the Scitor listing on the GitHub Marketplace and click Install.
Choose which repositories should receive support issues. You can grant access to all repositories or select specific ones. A dedicated support repository (e.g., yourorg/support) is recommended so customer issues stay separate from your product codebase.
Once installed, Scitor creates a setup issue in each selected repository. This issue contains your unique Scitor email address (something like abc123@scitor.io). You will need this address in the next step.
Step 2: Set up email forwarding (2 minutes)
Forward your customer-facing email address to the Scitor address you received.
Gmail / Google Workspace
- Open Settings > Forwarding and POP/IMAP.
- Click Add a forwarding address and enter your Scitor email address.
- Google sends a confirmation email. Scitor creates an issue with the confirmation code. Find it in your repository and enter the code in Gmail.
- Select Forward a copy of incoming mail and save.
Fastmail
- Go to Settings > Rules.
- Create a new rule with the condition “All messages” (or filter to a specific address).
- Set the action to “Forward to” and enter your Scitor email address.
- Save the rule.
Other providers
Most email providers support forwarding. Look for “Forwarding”, “Mail rules”, or “Routing” in your provider’s settings. The target address is always your Scitor inbound address.
Step 3: Configure with YAML (1 minute)
Create a .github/scitor.yaml file in your repository. A minimal configuration:
integration: issue
That is the only required setting. Incoming emails will now create GitHub Issues.
Want AI triage? Add:
integration: issue
ai: true
AI analysis is enabled by default on the Pro plan. It adds a one-line summary, sentiment labels, category classification, and priority assignment to every incoming message. Set ai: false to turn it off.
Want to use Discussions instead of Issues?
integration: discussion
Commit the file to your default branch. Scitor reads this configuration on every incoming message.
Step 4: Test it (1 minute)
Send a test email to your support address. Within a few seconds, a new GitHub Issue should appear in your repository with:
- The email subject as the issue title.
- The email body converted to Markdown.
- Sender information embedded in the issue.
- Any attachments uploaded and linked.
If you have the Pro plan with AI enabled, you should also see labels applied automatically for sentiment, category, and priority.
Step 5: Reply to the customer
Open the issue and write a comment with your response. At the end, add /send on its own line:
Hi there,
Thanks for reaching out. I've looked into this and the issue
is related to the API rate limit on your current plan.
You can check your current usage at https://example.com/usage.
Let me know if you have questions.
/send
Scitor converts your Markdown to a formatted HTML email and sends it to the customer. They see a professional email from your team, not a GitHub notification.
Optional: Customize the setup
Once the basics work, you can add more configuration over time:
Custom sending domain
By default, replies come from a Scitor address (no-reply@mail.scitor.io). To send from your own domain (e.g., support@yourcompany.com), you need to verify your domain’s SPF and DKIM records with Resend, then use the /set-from-address command:
/set-from-address support@yourcompany.com "Your Company Support"
See the custom email domain guide for the full setup.
SLA tracking
Set response and resolution targets:
sla:
first_response:
urgent: 1h
high: 4h
medium: 8h
low: 24h
resolution:
urgent: 4h
high: 24h
medium: 3d
low: 7d
business_hours:
timezone: America/New_York
start: "09:00"
end: "17:00"
days: [mon, tue, wed, thu, fri]
Saved replies
Store reusable templates as Markdown files in .github/scitor/replies/:
<!-- .github/scitor/replies/billing-faq.md -->
Hi {{customer_name}},
Here's a summary of our billing options...
Use them with /reply billing-faq.
Auto follow-ups
Nudge customers who have not responded:
follow_up:
auto:
enabled: true
waiting_on_customer: 3d
max_follow_ups: 2
auto_close_after: 14d
Full configuration options are documented in the post-install guide.
Common questions
Does this work with GitHub Organizations? Yes. Install the app at the organization level and select which repositories receive support.
Can I have multiple support repositories? Yes. Each repository gets its own Scitor email address and can have its own .github/scitor.yaml configuration.
What about spam? Scitor receives a SpamAssassin score with each inbound email and labels messages accordingly: spam:clean, spam:low, spam:medium, or spam:high. You can pair the spam labels with a GitHub Action to auto-close high-scoring messages.
Do customers need a GitHub account? No. Customers interact entirely via email. They never see GitHub.
Is there a web form option? Yes. Use the /create-form command on any issue and Scitor generates an embeddable JavaScript snippet for your website. Form submissions create issues just like emails do.
Recap
| Step | Action | Time |
|---|---|---|
| 1 | Install Scitor from GitHub Marketplace | 1 min |
| 2 | Set up email forwarding | 2 min |
| 3 | Add .github/scitor.yaml | 1 min |
| 4 | Send a test email | 1 min |
| 5 | Reply with /send | - |
Total setup time: under 5 minutes. No migration, no data import, no infrastructure to manage.
Get started now. Install Scitor from the GitHub Marketplace. Free plan, no credit card required.