|Read this if:||You're still experimenting, prototyping, and exploring.|
|Read first:||Building Slack apps|
|Read next:||Introducing Block Kit|
It's your Slack workspace. You want it to work with you. To work for you.
One way is to make integrations, bots, and other tools— just for your workspace. You can build with your team for your team. Or go it alone.
Here's what you can do with internal integrations on Slack.
Internal integrations can do what Slack apps can do. Internal integrations are Slack apps. They just integrate with the stuff you want them to.
When you're building just for your workspace, installing a Slack app is as easy clicking an install button. No one needs to learn OAuth if they don't want to.
Of course, OAuth is still here for you when you need it and you don't have to distribute your app to other workspaces to use it.
Sign in with Slack is one way to allow your members to sign in to an internal application with their Slack credentials.
It all depends on what your needs are. Use integrations to tie systems together, customize employee onboarding, reinforce cultural rituals, and send out those TPS reports everyone loves.
For an idea of what you can do with the Events API and an onboarding app, check out this example.
SSL is important, yes? Prevents all kinds of bad situations. But it does get in the way of developing locally or just sending a few requests to that server in the basement.
Accordingly, your internal integrations don't require SSL support on Events API request URLs, slash command invocations, interactive message action URLs, or OAuth redirect URLs.
If you ever decide your app should be shared with another team — even another team that's part of your Enterprise Grid, you'll need to support SSL for all these things.
Slack also supports several ways to verify the authenticity of its requests to your app. Read more in the verifying requests from Slack documentation.