.png)
Slack Integration Guide
Connect Slack workspaces with enterprise systems through the Slack Web API, event callbacks, incoming webhooks, interactive requests, and OAuth 2.0.
Slack integration options at a glance
Slack integrations use the HTTP-based Web API for messages, conversations, users, files, and related application capabilities. The Events API provides selected event notifications through configured request URLs, while slash commands and interactive components send request callbacks to an application endpoint. Incoming webhooks support focused outbound notifications, and OAuth 2.0 provides workspace authorization through bot or user tokens and granular scopes. Martini can consume Slack APIs from workflows, expose endpoints for callbacks, verify signed requests, transform JSON payloads, paginate through history or list methods, and coordinate retries, reconciliation, and downstream updates.
| Integration point | Supported by Slack? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Slack's Web API provides method endpoints such as chat.postMessage, conversations.history, conversations.replies, users.list, and file operations for messages, conversations, users, files, and related capabilities. | Martini can consume Slack HTTP APIs from workflows, configure authorization, parse JSON responses, follow cursor pagination, transform fields, and expose downstream APIs. |
| Webhooks and event callbacks | Yes | The Events API sends selected subscribed events to a request URL. Slash commands and interactive components also send HTTP request payloads, subject to scopes, app type, conversation access, and workspace policy. | Martini can expose callback endpoints, verify Slack signatures, acknowledge requests promptly, and invoke asynchronous workflows for longer processing. |
| Incoming webhooks | Yes | Incoming webhooks post messages to a designated Slack conversation and are suitable for operational alerts and focused notifications. | Martini workflows can call the webhook URL, map source payloads to Slack text or supported message structures, and handle response failures and retries. |
| Bulk, batch, and incremental access | Limited | Slack primarily provides paginated method-based access rather than one universal bulk API. Specialized export, audit, discovery, and compliance capabilities may depend on plan and administrative permissions. | Martini can implement cursor-based pagination, checkpoint timestamps or cursors, bounded reconciliation workflows, and controlled batch processing. |
| File and attachment APIs | Yes | Slack provides file objects and upload or retrieval operations, including a newer external upload flow involving an upload URL and completion step. | Martini can retrieve file metadata, upload or forward approved files, map sharing details, and enforce retention and security rules in workflows. |
| Authentication | Yes | Slack supports OAuth 2.0 app installation, bot and user tokens, app-level tokens for selected capabilities, granular scopes, and signing-secret request verification. | Martini can store tokens and signing secrets as protected configuration, call Slack with the appropriate authorization, and validate inbound request signatures. |
| SDKs | Yes | Slack provides official SDKs and developer tools for several languages, although standard HTTP integration is the documented Martini approach for these patterns. | Martini does not require an SDK to consume Slack APIs or receive HTTP callbacks; custom JVM-compatible logic can be used when standard workflow steps are insufficient. |
How Slack exposes data and business events
Slack Web API
Slack's Web API is an HTTP method-based interface for conversations, messages, users, files, reactions, and other app capabilities. Requests and responses generally use JSON, authorization is scope-dependent, and many list or history methods use cursor pagination.
Martini implementation pattern
Martini implementation pattern: a workflow invokes the required Slack method with protected OAuth credentials, validates the response, follows pagination or checkpoints, maps Slack objects into a canonical model, and writes the result to a target system or exposes it through a Martini API.
Implementation sequence
Slack Events and callbacks
Slack's Events API sends selected subscribed events to a configured request URL. Slash commands and interactive components send related HTTP callbacks, but event coverage depends on subscriptions, scopes, app type, conversation access, and workspace policy.
Martini implementation pattern
Martini implementation pattern: expose a controlled endpoint, verify the Slack signing secret and timestamp, acknowledge the request promptly, and hand longer-running work to a workflow. The workflow deduplicates event IDs or domain identifiers before calling downstream APIs.
Implementation sequence
Slack incoming webhooks
Incoming webhooks allow an external system to post messages to a designated Slack conversation through a webhook URL. They are suited to notifications and alerts rather than general workspace synchronization.
Martini implementation pattern
Martini implementation pattern: receive an alert or business event through an API or trigger, transform it into the required Slack message structure, call the configured webhook, and record the source identifier and delivery result for troubleshooting and duplicate prevention.
Implementation sequence
Slack file operations
Slack provides file objects and file upload or retrieval operations. The newer external upload flow uses an upload URL followed by upload completion, while access and sharing depend on scopes and workspace permissions.
Martini implementation pattern
Martini implementation pattern: retrieve or receive approved file metadata, obtain or use the appropriate Slack upload or download operation, transfer content through a controlled workflow, and apply retention, access, and error-handling rules.
Implementation sequence
Common Slack integration patterns
Pattern 1: Deliver enterprise alerts to Slack
When to use this pattern
Use this pattern when incidents, CRM events, deployment results, or operational alerts need to reach the right Slack conversation. It supports channel routing, consistent formatting, correlation with the source event, and controlled retries without embedding Slack-specific logic in every source application.
Integration direction
Example Mapping
| Slack Field | Canonical Field | Target Field |
|---|---|---|
| incident.number | sourceEventId | message metadata or correlation record |
| incident.short_description | summary | message text |
| incident.priority | severity | routing rule and message emphasis |
| incident.assignment_group | owner | Slack conversation selection |
Martini implementation pattern
Martini receives an incident or alert through an API, trigger, or source-system workflow, maps it into a canonical notification model, selects a Slack conversation using severity and ownership rules, and calls chat.postMessage or an incoming webhook. The workflow stores the source ID and Slack timestamp, retries transient failures with backoff, and avoids duplicate notifications during replay.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Create business actions from Slack requests
When to use this pattern
Use this pattern when users need to submit structured requests from a slash command, interactive component, or selected message without receiving direct access to a downstream application. Examples include creating a Salesforce Case, Zendesk ticket, or ServiceNow Incident from a controlled Slack interaction.
Integration direction
Example Mapping
| Slack Field | Canonical Field | Target Field |
|---|---|---|
| command.text | requestDescription | incident.description |
| user_id | requesterId | caller or requester reference |
| channel_id | sourceConversationId | correlation metadata |
| response_url | acknowledgementTarget | follow-up response route |
Martini implementation pattern
Martini exposes a callback endpoint for the Slack request, verifies the signing secret and timestamp, acknowledges promptly, and starts a workflow for validation and downstream processing. The workflow applies command-specific business rules, creates or updates the target object, and posts a concise result back to Slack while using a request identifier to prevent duplicate actions.
Martini capabilities used
- APIs
- workflows
- authentication and authorization
- data mapping
- business rules
- error handling
Pattern 3: Synchronize Slack users and conversations
When to use this pattern
Use this pattern for controlled reconciliation between Slack workspace data and an authoritative HR, identity, or collaboration system. It is appropriate where user or conversation visibility is permitted and where event coverage alone is insufficient for consistency.
Integration direction
Example Mapping
| Slack Field | Canonical Field | Target Field |
|---|---|---|
| user.id | externalUserId | worker or identity external ID |
| user.profile.display_name | displayName | preferred display name |
| conversation.id | externalConversationId | channel or workspace reference |
| conversation.is_private | visibility | access policy |
Martini implementation pattern
A scheduled Martini workflow calls Slack user and conversation methods, follows cursor pagination, normalizes the responses, and compares them with approved Workday or identity data. It records deltas, applies administrative safeguards, and routes exceptions for review rather than assuming that an ordinary bot token can perform workspace-wide changes.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data mapping
- business rules
- monitoring
Pattern 4: Capture Slack messages and files for case processing
When to use this pattern
Use this pattern when selected Slack messages, threads, or files must be associated with support cases, incidents, or document processes. It should be limited to permitted conversations and approved content types because Slack events are selected rather than a universal activity feed.
Integration direction
Example Mapping
| Slack Field | Canonical Field | Target Field |
|---|---|---|
| event.message.ts | sourceMessageId | external message reference |
| event.message.text | content | ticket comment or description |
| event.message.thread_ts | parentThreadId | ticket conversation reference |
| file.id | sourceFileId | attachment external ID |
Martini implementation pattern
Martini receives a permitted message or interaction event, validates and deduplicates it, retrieves current message or file details when necessary, and maps the content into a Zendesk ticket or comment. The workflow preserves conversation and thread identifiers, applies file retention rules, and retries downstream operations without creating duplicate case activity.
Martini capabilities used
- webhook consumption
- workflows
- JSON handling
- data mapping
- file handling
- error handling
Applications commonly integrated with Slack
Slack is commonly used as an operational and collaboration layer alongside business applications. Martini can orchestrate notifications, structured commands, callbacks, synchronization, and data transformation between Slack and these named systems without requiring a dedicated Slack connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Send CRM alerts to sales channels and create or update follow-up records from controlled Slack requests. | Salesforce → Martini → Slack | A Martini workflow consumes Salesforce events or scheduled API results, applies routing and message-formatting rules, and calls Slack chat.postMessage or an incoming webhook. A separate Martini endpoint can validate Slack commands or interactive payloads before updating Salesforce. |
| ServiceNow | Notify operations teams about incidents and support selected incident actions from Slack. | ServiceNow → Martini → Slack | Martini receives ServiceNow incident data, maps severity and ownership to Slack channels, and posts threaded notifications. Slack callbacks can be signature-validated, converted into ServiceNow updates, and protected with idempotency and retry rules. |
| Jira | Publish issue updates, sprint notifications, approvals, and deployment-related status to project channels. | Jira → Martini → Slack | A Martini workflow consumes Jira API responses or callbacks, transforms issue fields into Slack text or blocks, and posts messages with correlation metadata. Selected Slack commands can be routed back to Jira for issue creation or transitions. |
| Zendesk | Route support escalations to Slack and create or update tickets from controlled Slack interactions. | Zendesk → Martini → Slack | Martini maps Zendesk ticket events to Slack notifications and stores ticket identifiers with Slack timestamps. A Slack slash command or interactive request can invoke a Martini API that validates the request and calls Zendesk for permitted ticket actions. |
| PagerDuty | Deliver incident notifications to response channels and support selected acknowledgement or escalation workflows. | PagerDuty → Martini → Slack | Martini receives PagerDuty notifications, applies severity and service routing rules, and posts concise Slack messages. Interactive Slack actions can be validated and forwarded to PagerDuty, with duplicate protection based on the incident identifier. |
| GitHub | Notify development channels about pull requests, reviews, deployments, and workflow results. | GitHub → Martini → Slack | A Martini workflow consumes GitHub webhook or API data, normalizes repository and pull-request fields, and posts to the appropriate Slack conversation. Business rules can suppress noisy events and preserve links, authors, and deployment status. |
| Workday | Coordinate employee lifecycle information with Slack user and access processes where administrative permissions allow it. | Workday → Martini → Slack | A scheduled Martini workflow retrieves approved Workday changes, compares them with Slack Users and workspace policy, and produces controlled provisioning or exception actions. Administrative operations remain subject to Slack scopes, workspace permissions, and organizational approval. |
| Microsoft Teams | Support cross-platform notifications, migration, or coexistence scenarios between collaboration environments. | Slack → Martini → Microsoft Teams | Martini consumes selected Slack events or messages, maps them to the Teams API model, and applies filtering, threading, and identity rules before delivery. The reverse direction can be implemented through Teams events or APIs where available. |
How to build a Slack integration in Martini
Objective
Establish the Slack app authorization and protected configuration required by the integration.
Instructions in Martini
- Create or configure the Slack app and identify required Web API methods, event subscriptions, or webhook features.
- Use OAuth 2.0, bot or user tokens, and only the granular scopes required by the workflow.
- Store tokens, webhook URLs, and the Slack signing secret in protected Martini configuration.
Objective
Select an API-led, event-driven, webhook, or scheduled entry point based on the required timeliness and Slack coverage.
Instructions in Martini
- Use a Martini API endpoint for Slack Events API, slash command, or interactive callbacks.
- Use a workflow trigger or scheduler for polling, reconciliation, user synchronization, or history retrieval.
- Use an inbound source API or event to initiate outbound Slack notifications.
Objective
Retrieve or receive Slack data while validating request authenticity, response status, and required fields.
Instructions in Martini
- Verify Slack callback signatures and timestamps before processing inbound requests.
- Call the required Web API method and handle cursor pagination for list or history responses.
- Capture event IDs, message timestamps, conversation IDs, file IDs, or other correlation values.
Objective
Coordinate validation, enrichment, routing, downstream calls, and acknowledgement in a maintainable Martini workflow.
Instructions in Martini
- Acknowledge interactive or event callbacks promptly and separate long-running work when needed.
- Use conditional routing for severity, conversation, workspace, permission, or object-type rules.
- Persist checkpoints and processing status for incremental synchronization and reconciliation.
Objective
Convert Slack JSON objects and callback payloads into canonical models and target-specific requests.
Instructions in Martini
- Map Users, Conversations, Messages, Threads, and Files using stable external identifiers.
- Normalize message text, blocks, timestamps, thread relationships, and source metadata according to the target model.
- Tolerate optional or newly added Slack fields while validating required properties.
Objective
Enforce permissions, routing, retention, deduplication, and business decisions before side effects occur.
Instructions in Martini
- Check that the token, app, and conversation access support the requested operation.
- Apply channel and severity routing, permitted file handling, and private-conversation safeguards.
- Use idempotency keys based on event IDs, message timestamps, file IDs, or source-system identifiers.
Common Slack data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Users | Synchronize workspace members, display names, permitted profile fields, and status information with HR, identity, or operational systems. | Workday, Okta, Microsoft Entra ID, Salesforce | Martini retrieves Users through Slack methods, follows pagination, applies scope and privacy rules, compares records with an authoritative system, and stores correlation identifiers. |
| Conversations | Represent public channels, private channels, direct messages, and group direct messages for routing, access checks, history retrieval, and notification delivery. | ServiceNow, Jira, Salesforce, Microsoft Teams | Martini uses conversation identifiers and permissions to select destinations, retrieve history, and apply channel-specific routing rules without assuming workspace-wide visibility. |
| Messages | Post notifications, capture structured requests, synchronize selected message activity, and correlate replies or updates. | ServiceNow, Salesforce, Zendesk, Jira | Martini maps text, blocks, links, timestamps, and metadata, retaining the conversation ID and message timestamp for updates, threading, deduplication, and reconciliation. |
| Files | Distribute documents, process selected uploads, or forward approved file metadata and content to downstream storage or case-management systems. | SharePoint, Google Drive, Zendesk, ServiceNow | Martini invokes file-related API operations, applies scope and retention rules, and separates metadata handling from content transfer where required. |
| Threads | Group message replies under a parent message for incident discussions, support requests, approvals, and contextual updates. | ServiceNow, PagerDuty, Salesforce, Jira | Martini preserves the parent message timestamp, maps replies to the related business object, and prevents duplicate thread notifications through correlation keys. |
| Apps | Represent installed Slack applications, bot identities, permissions, event subscriptions, and interactive features during solution design and administration. | Identity platforms, administration stores, audit processes | Martini can use app and authorization metadata where exposed and can maintain configuration references, but administrative operations remain subject to Slack permissions and workspace policy. |
Authentication and security considerations
OAuth and scopes
Slack uses OAuth 2.0 app installation to authorize workspaces and issue bot or user tokens. Granular scopes determine which Web API methods, conversations, files, and events are available.
Request verification
Public Martini endpoints receiving Events API notifications, slash commands, or interactive payloads should verify Slack's signing secret and validate request timestamps to reduce replay risk.
Secrets and least privilege
- Store OAuth tokens, app-level tokens, webhook URLs, and signing secrets in protected Martini configuration.
- Request only the scopes required for the specific workflows.
- Do not assume that a bot can read private channels, direct messages, or all workspace users.
- Control file downloads, sharing, retention, and downstream exposure.
Operational considerations for Slack integrations
Rate limits and pagination
Slack applies rate limits across methods, apps, workspaces, and token contexts. Workflows should honor Retry-After when supplied, use bounded backoff, avoid unnecessary polling, and follow cursor pagination until no next cursor remains.
Events and acknowledgement
Slack event and interaction delivery should be treated as at-least-once from an integration design perspective. Acknowledge callbacks promptly, then process longer-running work asynchronously where appropriate.
Idempotency and reconciliation
Persist event IDs, file IDs, source identifiers, or the conversation ID and message timestamp together. Combine event processing with scheduled reconciliation when event coverage, permissions, or historical consistency may be incomplete.
Schema and workspace variation
Validate required fields while tolerating optional fields and new event properties. Confirm workspace plan, administrative approval, app membership, private-conversation access, and retention requirements before depending on specialized capabilities.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini provides a maintainable place to coordinate Slack API calls, callbacks, incoming webhooks, downstream systems, business rules, and asynchronous processing instead of duplicating logic across scripts.
Reusable data handling
Workflows can normalize Slack Users, Conversations, Messages, Threads, and Files into canonical models, apply mappings and transformations, and reuse validation, routing, and correlation logic across integrations.
Operational control
Martini can centralize protected configuration, callback verification, pagination, retries, idempotency, checkpoints, and monitoring. This makes Slack integrations easier to test, troubleshoot, and evolve as permissions and event payloads change.
API-led architecture
Martini can consume Slack APIs and expose controlled APIs to downstream applications, reducing point-to-point dependencies while preserving the flexibility to add custom JVM-compatible logic when standard workflow steps are insufficient.
Frequently asked questions
Slack can be integrated through its HTTP-based Web API, Events API callbacks, incoming webhooks, slash commands, interactive request payloads, file operations, and OAuth 2.0 authorization. Enterprise workflows commonly use the Web API for messages, conversations, users, and files, while selected events and user interactions enter through configured request URLs.
Yes. Martini can consume Slack's Web API, call incoming webhooks, expose endpoints for Events API callbacks, slash commands, and interactive payloads, verify Slack signatures, and orchestrate transformations and downstream actions. No native Martini Slack connector is documented in the supplied sources.
No. A dedicated Slack connector is not required. Martini can integrate using Slack's confirmed native mechanisms, including the Web API, OAuth 2.0, event and interaction callbacks, incoming webhooks, and file-related APIs.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Slack. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Slack, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
The Slack Web API is the primary method for reading and writing messages, conversations, users, and files. Use the Events API, slash commands, or interactive callbacks for selected inbound activity, and incoming webhooks for focused outbound notifications. Slack's documented application API surface is not GraphQL or SOAP.
No. Slack provides selected Events API event types and HTTP callbacks for subscribed interactions. Availability depends on event subscriptions, OAuth scopes, app type, conversation access, and workspace policy, so a scheduled reconciliation workflow may still be needed.
Martini can combine event-driven processing with scheduled calls to Slack list or history methods. Workflows follow cursor pagination, persist timestamps or cursors, deduplicate event IDs and domain identifiers, map Slack objects into a canonical model, and reconcile gaps where event visibility or permissions are incomplete.
Workflows can detect rate-limit responses, honor Retry-After when returned, use bounded backoff, and separate interactive processing from high-volume synchronization. Idempotency can be based on event IDs, conversation and message timestamps, file IDs, or source-system identifiers. Martini can also expose an API façade for downstream consumers while centralizing Slack authentication, validation, mapping, and error handling.
Related Martini documentation
Slack APIs
Data handling
Connect Slack with your enterprise systems
Use Martini to build secure, API-led Slack integrations with workflows, callbacks, transformations, business rules, and operational controls.