> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Create API credentials, webhooks and custom apps

> Connect your own systems with explicit permissions and observable delivery.

<Note>
  This guide includes features awaiting release. If an option is not available in your workspace, contact StackShift Support.
</Note>

## What you can do

Connect your own systems with explicit permissions and observable delivery. Where to find it: Settings → Integrations → Developer and Credentials

## Before you start

* Integration management permission and a developer maintaining the receiving system.
* An HTTPS webhook destination you control when using webhooks.

## Steps

<Steps>
  <Step>
    Create a scoped credential for the intended workspace and environment. Save its one-time secret in protected server configuration; choose the smallest permissions your integration needs.
  </Step>

  <Step>
    For outgoing events, create a webhook with the desired events and destination. Implement the documented signature verification before acting on received data.
  </Step>

  <Step>
    Send a webhook test and inspect delivery history. Handle duplicate delivery safely and distinguish retryable failures from a successful action whose response was lost.
  </Step>

  <Step>
    For a custom app, use Developer to configure installation consent, registered actions, execution grants and signing keys as applicable. Test within its granted scope.
  </Step>

  <Step>
    Rotate credentials and signing keys through their controls, update the receiving application and verify operation before retiring old access. Revoke integrations no longer needed.
  </Step>
</Steps>

## Example

A webhook notifies your internal system that a ticket changed; the receiver verifies the signature and processes an event only once.

## Things to know

* Public widget keys do not replace server API credentials.
* API clients should retain the same Idempotency-Key and original payload for an uncertain retry; revision-protected changes need the current If-Match value.
* Custom actions require an explicit execution grant; registering an app does not authorize arbitrary business operations.

## What happens next

<Check>
  Your integration has a known scope and a way to inspect failed deliveries or action outcomes.
</Check>

## If something goes wrong

<Warning>
  * Permission denied: compare credential scope and current workspace/inbox authority.
  * Webhook failed: inspect response status and signature verification; do not expose signing secrets in logs.
  * Stale revision: reload the current record, review changes and submit again.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Connect business tools to Support" href="/stackshift-support/integrations">
    Bring useful customer context and approved actions into conversations.
  </Card>

  <Card title="Support organizations and permissions" href="/stackshift-support/organizations-and-permissions">
    Group workspaces, invite staff and grant only the access each person needs.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.