L’API Web est une collection de méthodes de type HTTP RPC, toutes avec des URL sous la forme https://slack.com/api/METHOD_FAMILY.method.
Bien qu’il ne s’agisse pas d’une API REST, ceux qui sont familiers avec REST devraient être à l’aise avec ses fondations en HTTP.
Utilisez HTTPS et SSL lors de l’appel de toutes les méthodes.
Chaque méthode dispose d’une série d’arguments informant l’exécution de vos intentions.
Passez les arguments comme suit :
- Paramètres de chaîne de requête GET
- Paramètres POST présentés sous la forme
application/x-www-form-urlencoded - ou un mélange des paramètres GET et POST
- Certaines méthodes d’écriture autorisent les attributs arguments
application/json - [
files.upload] expectsmultipart/form-data, which is a fancy way of asking you to send most parameters asapplication/x-www-form-urlencodedkey/value pairs but send files in their native content type.
Some methods, like chat.postMessage and dialog.open feature arguments that accept an associative JSON array. These methods can be difficult to properly construct when using a application/x-www-form-urlencoded Content-type, and we strongly recommend using JSON-encoded bodies instead.
POST bodies
When sending a HTTP POST, you may present your arguments as either standard POST parameters or use JSON instead.
URL-encoded bodies
When sending URL-encoded data, set your HTTP Content-type header to application/x-www-form-urlencoded and present your key/value pairs according to RFC-3986.
For example, a POST request to conversations.create might look something like this:
POST /api/conversations.create
Content-type: application/x-www-form-urlencoded
token=xoxa-xxxxxxxxx-xxxx&name=something-urgent
All Web API responses contain a JSON object, which will always contain a top-level boolean property ok, indicating success or failure.
For failure results, the error property will contain a short machine-readable error code. In the case of problematic calls that could still be completed successfully, ok will be true and the warning property will contain a short machine-readable warning code (or comma-separated list of them, in the case of multiple warnings).
{
"ok": true,
"stuff": "This is good"
}
{
"ok": false,
"error": "something_bad"
}
{
"ok": true,
"warning": "something_problematic"
"stuff": "Your requested information"
}
Other properties are defined in the documentation for each relevant method. There's a lot of "stuff" to unpack, including these types and other method or domain-specific curiosities.
Authenticate your Web API requests by providing a bearer token, which identifies a single user, bot user, or workspace-application relationship.
Register your application with Slack to obtain credentials for use with our OAuth 2.0 implementation, which allows you to negotiate tokens on behalf of users and workspaces.
We prefer tokens to be sent in the Authorization HTTP header of your outbound requests. However, you may also pass tokens in all Web API calls as a parameter called token.
Treat tokens with care. Never share tokens with other users or applications. Do not publish tokens in public code repositories. Review token safety tips.
One way to understand all the magic behind the methods is to investigate our OpenAPI 2.0 specification, describing the requests and responses you'll find throughout our Web API.
- Download the spec from its canonical location on api.slack.com
- Brose the spec's history on github
With over 100 methods, surely there's one right for you. Here is a list of the different method families available in our Web API:
- api
- apps.permissions
- apps.permissions.resources
- apps.permissions.scopes
- apps.permissions.users
- apps
- auth
- bots
- channels
- chat
- conversations
- dialog
- dnd
- emoji
- files.comments
- files
- groups
- im
- migration
- mpim
- oauth
- pins
- reactions
- reminders
- rtm
- search
- stars
- team
- team.profile
- usergroups
- usergroups.users
- users
- users.profile
Information taken from Slack API website.
