You're handing us your App Store Connect API key. That's a big deal. It grants access to your apps, your builds, your tester data. We know that. So we designed Yeethook so you don't have to trust us. You just have to verify.
How we store your p8 key
Your .p8 key is encrypted with AES-256-GCM before it touches the database. The encryption key lives separately from the database and is never committed to source control. Even if someone compromised the database, the raw key material would be unreadable without the encryption key.
Once uploaded, your API key content is never sent back to the browser. The dashboard shows metadata (Key ID, the label you chose) but never the key itself. There's no "show key" button. There's no API endpoint that returns it. The key only exists in plaintext for the brief moment it's decrypted server-side to authenticate with Apple's API.
Three things happen with your key:
- Registering App Store Server Notification URLs for your apps
- Configuring App Store Connect webhooks on your behalf
- Fetching additional context (crash logs, tester details, screenshots) to enrich Slack messages
After each API call, the decrypted key is discarded from memory.
Slack is one-way only
The Yeethook Slack app uses a single permission: Incoming Webhooks. That's the most restricted scope Slack offers. It lets Yeethook post messages to one specific channel that you choose during setup. That's it.
The app cannot read messages, access files, list channels, see user profiles, or receive any data from your workspace. There are no event subscriptions, no slash commands, no Socket Mode connection. Data flows in one direction: from Apple, through Yeethook, to your Slack channel. Nothing comes back.
You can revoke access instantly
Both sides of Yeethook's access are fully under your control, and you can cut either one at any time.
Apple side. Go to App Store Connect and revoke the API key. Yeethook immediately loses the ability to call Apple's APIs on your behalf. No need to contact us. No waiting period.
Slack side. Go to your Slack app configuration and remove the incoming webhook URL. Yeethook can no longer post to that channel. You can also remove individual webhook URLs without deleting the entire app.
You don't need our permission to cut us off. That's by design.
A familiar pattern
If you've used Expo Application Services (EAS), this model is familiar. EAS asks you to log into your Apple Developer account, creates a p8 key, downloads it, stores it on their servers, and uses it to manage builds, submissions, and credentials on your behalf. Thousands of React Native teams trust this workflow every day.
Yeethook works the same way. You upload your p8 key, we encrypt it, and we use it to configure webhooks and enrich events. The difference is you bring your own key instead of having it created automatically, which means you know exactly which key Yeethook has and can revoke it independently at any time.
Don't want to share your key? Don't.
We get it. Some teams have policies against sharing API keys with third-party services. That's why Yeethook offers a Manual Setup option.
With Manual Setup, you create the webhooks in App Store Connect yourself. We give you step-by-step instructions and the exact URLs to use. Yeethook receives the webhooks and delivers formatted Slack messages for every event type.
The tradeoff: without a p8 key, Yeethook can't call the App Store Connect API. That means no enrichment. You'll get a notification that says "a crash was submitted" but not the crash log, the tester's name, or the device model. For teams that prioritize keeping their keys in-house, that's a fair exchange. You still get real-time Slack notifications for every Apple event.
Recommendations
- Use a dedicated API key for Yeethook. Don't share one across services.
- Choose the Admin role when creating the key. This is required for webhook management.
- Keep a backup of your .p8 file in a secure location. Apple only lets you download it once.
Your keys. Your control. We just encrypt them and put them to work.