Slack's Web API is organized around conversations (channels, DMs, group DMs), users, files, messages, and workspace/admin resources. Most day-to-day actions — sending or editing messages, uploading files, examining members — use conversation and user identifiers. Admin/enterprise actions live under distinct admin.* methods and typically require extra scopes and workspace (team) identifiers.

Key entities and where to get their IDs

• Conversations / channels: almost every conversations- and chat-related method needs a conversation identifier (channel / channel_id). Get these from conversations.list or users.conversations (filter by types as needed). For a DM with a specific user, open (or ensure) a DM with conversations.open and use the returned channel.

• Users: many actions require a user ID (user). To find a user by email use users.lookupByEmail. For broad lists use users.list. users.conversations can enumerate channels a user belongs to.

• Teams / workspaces: admin and org-level methods often require team_id or enterprise_id. The current token's team is visible in auth.test (returns team_id). Admin flows may need workspace IDs returned from admin_teams_list or admin_conversations_getTeams.

• Messages: messages are identified by ts (timestamp) returned by chat.postMessage and many history/reply endpoints. Use that ts for chat.update, chat.delete, chat.getPermalink, and conversations.replies (thread parent thread_ts).

• Files: files.upload returns a file object with an ID; use files.info or files_sharedPublicURL/files_revokePublicURL to manage sharing. For remote-file flows, methods accept either file (Slack ID) or external_id (app GUID); one of them is usually required.

• Views/dialogs/workflows: view payloads and dialogs are submitted as stringified view/dialog parameters (view, dialog, inputs, outputs). Where the signature calls for a JSON-encoded view or dialog provide the view as a single string value matching the API's expected view object structure.

Authentication and scopes (practical notes)

• Many methods require an OAuth token; check the operation signature to see whether that token appears as a header parameter (token in the header) or as a query parameter (token in the query). Provide the token in the exact parameter location the operation's signature shows.

• Admin and enterprise operations require specialized admin scopes (for example admin.*, admin.conversations:*, admin.users:*) and often only operate at the workspace/org level. If a user asks for admin tasks, confirm that the token has the appropriate admin scopes and that a team_id (or enterprise_id) is supplied when required.

Common tasks and the typical operation sequence

Each example below states the minimal sequence of calls and which IDs you need to obtain along the way. Use the exact parameter names shown in each operation's signature.

• Send a message to a public/private channel by name

  1. Find the channel ID: call conversations.list and filter by name (or use users.conversations if looking for channels for a particular user). conversations.list returns channel objects in channels and may include response_metadata.next_cursor for pagination.
  2. Call chat.postMessage with the channel ID and text (and optional blocks, attachments). The response includes ts and the posted message object.

• Send a direct message to a user (by email)

  1. Get the user ID: call users.lookupByEmail with email.
  2. Open a DM: call conversations.open with the user (or users list). Inspect the returned channel — watch for already_open and for the returned shape (some responses provide a conversation object or arrays). Use the returned channel's id.
  3. Call chat.postMessage with that DM channel ID.

• Update or delete a specific message

  • Use the channel and the message ts returned when the message was posted. For updates call chat.update. For deletion call chat.delete (or chat_deleteScheduledMessage for scheduled messages) using the same channel + ts (or scheduled_message_id for scheduled items).

• Schedule, list, and cancel scheduled messages

  1. chat.scheduleMessage returns scheduled_message_id and post_at and the scheduled message summary.
  2. List scheduled messages with chat.scheduledMessages.list (filter by channel, oldest, latest as needed). Look for response_metadata.next_cursor for pagination.
  3. Delete a scheduled message with chat.deleteScheduledMessage using the scheduled_message_id (or the operation signature's required fields).

• Work with threads and replies

  • Use conversations.replies with the parent message ts (thread_ts) and the channel to fetch thread replies. To post a reply, call chat.postMessage with thread_ts set to the parent ts and the channel.

• Upload and share a file

  1. Call files.upload (supply channels if immediate sharing is desired). The response includes the file object.
  2. To make a file public, call files.sharedPublicURL; to revoke public access call files.revokePublicURL.
  3. For remote files (registered by an app), use files.remote.* methods; sharing requires either file or external_id per the method signature.

• Pinning, starring, reacting

  • Pin a message or file with pins.add. Remove with pins.remove. Add emoji reactions with reactions.add and remove with reactions.remove. To list pins or stars, use pins.list and stars.list (note some list responses can be paginated or returned as different shaped payloads — inspect the response).

• Post ephemeral messages

  • Use chat.postEphemeral and provide both channel and user. Ephemeral messages are targeted to the user and do not appear to others.

• Open views, update views, and use trigger-based flows

  • views.open and views.push require a trigger_id and a view payload (string). views_publish requires user_id and a view string. views_update requires view_id or external_id and the view string; it may also accept a hash to prevent race conditions.

• User profile and presence

  • Read profile with users.profile.get (pass user optionally). Update with users.profile.set (requires the write scope). Presence can be read with users.getPresence and changed with users.setPresence.

Admin and org-level patterns (non-obvious details)

• Admin endpoints are separate (admin.*). These perform org-level operations: approving or restricting apps (admin.apps_*), creating teams (admin.teams_create), managing workspace users (admin.users_*), and creating or managing organization conversations (admin.conversations_*). They usually require: an admin token with the specific admin scopes, and sometimes an explicit team_id or enterprise_id parameter. Verify which identifier the specific admin call expects.

• Admin conversation methods sometimes return only ok without the full conversation object, or they return different field names for created IDs (e.g., channel_id vs channel). Check the exact operation response for which field contains the new ID.

• Listing approved or restricted apps and invite requests uses paginated responses with cursor/next_cursor. Limits vary across admin calls (read the operation signature for allowed limit ranges).

Response and schema quirks to watch for

• Token parameter location varies. Some operations declare token in the header; others accept it in the query. Provide the token exactly as the operation signature requires.

• Inconsistent field names for new or returned IDs. Examples: conversations.create returns a channel object; admin.conversations.create may return channel_id. Always inspect the success response for the field that holds the created resource ID.

• conversations.open and some other endpoints can return different shapes depending on the call (single object vs array, already_open flags, or additional fields). Do not assume a fixed shape—use the actual response.

• Some endpoints require JSON-structured strings for parameters (for example view, dialog, inputs, outputs). The signature will note when a parameter is a JSON-encoded string; supply the view/dialog as a single string matching the API's view format.

• Pagination is common and uses cursor / response_metadata.next_cursor. Many list endpoints also return a limit and may have operation-specific maximums (check the operation signature for allowed limit ranges).

• Some operations in the surface list have incomplete or terse response schemas (responses that show only ok: true or body: never). For these, inspect the response payload for the useful fields instead of assuming a consistent schema.

Practical checks before making changes

• Confirm the token has the required scopes for the requested operation. Admin actions require admin-specific scopes; posting/reading messages require chat:* or conversations:* or users:* scopes as indicated in the operation signature.

• When doing cross-workspace or org-level work, confirm whether a team_id or enterprise_id is required and obtain it (for the current token auth.test returns the active team_id).

• When interacting with messages, always capture ts and channel from the response to reference that message later (updates, deletes, permalinks, replies).

Quick patterns (one-line reminders)

• Find a user by email: users.lookupByEmail -> open DM: conversations.open -> post: chat.postMessage.
• Find a channel by name: conversations.list (filter channels by name) -> post: chat.postMessage.
• Edit/delete a message: use the channel + message ts returned from the original post.
• Schedule a message: chat.scheduleMessage -> list scheduled: chat.scheduledMessages.list -> delete scheduled: chat.deleteScheduledMessage.
• Upload and share a file: files.upload -> manage public link: files.sharedPublicURL / files.revokePublicURL.

Use the operation signatures to confirm required fields, where to place the token, and whether a parameter expects a JSON string. The API surface exposes both end-user and admin operations; pick workspace-level identifiers (channel, user, team) from the appropriate list/info calls before calling mutation endpoints.