For the things you ship

Developer notifications.
In the conversation.

Build results, deployment notifications, and alerts belong where your team can act on them. Send them to Fryll with a conversation token and one HTTP request.

Start a workspace Compare your options

Terminal

~/api $

#deploys

CI10:03 AM

Build #419 passed on main

Emma Collins10:15 AM

Staging looks good. Smoke tests are green.

Illustrative demo · your token posts as you by default.

Your first notification

A token. A request. You’re connected.

No app registration or OAuth flow for token posting. Start with a channel your team already uses, or give notifications a home of their own.

Choose the conversation.

Create a workspace and a channel such as #deploys. You can also send to a DM. The token belongs to you and is scoped to that conversation.

Generate your token.

Open the conversation’s Details, then Your conversation token. Generate it and save the secret in your CI provider or server’s secret store as FRYLL_TOKEN. It is shown once.

Send the update.

Run this request with curl. A successful response is 201 Created and includes the message ID, which you can use for a thread reply.

curl --fail --silent --show-error \
  --connect-timeout 5 --max-time 15 \
  --header "Content-Type: text/plain" \
  --data-binary "Deployed api v1.42.1 to production" \
  "https://api.fryll.com/in/$FRYLL_TOKEN"

Read the notification API guide →

Useful signals, shared context

The update is where the discussion happens.

A build fails. A teammate asks what changed. The reply, the fix, and the next successful run can stay in the same conversation.

Use channels for projects and environments. Use thread replies to keep a deployment’s start, checks, and outcome together. Send the facts people need: project, environment, outcome, and a link to the logs.

#builds

Build #421 failed on main. Open the workflow run to see the failing test.

#deploys

API v1.42.1 is live in production. Health checks passed.

#operations

Nightly backup completed. 18 archives verified.

Fits the tools you already use

If it can make an HTTP request, it can post.

Use curl from a CI step or shell script. Send plain text, form fields, or JSON from your application. Add an optional agent name when a service should have its own identity.

The conversation token posts messages; it is not a general API credential for reading history. Rotate or revoke it in the same conversation’s details.

GitHub Actions build and deployment results
Scripts, backups, and scheduled job outcomes
Application events and operational alerts
Named agents and updates inside threads

These use Fryll’s HTTP endpoint. A script example is not a separately installed provider integration.

A few useful answers

Before you get started.

Is this a webhook notification endpoint?

Yes: send an HTTP POST to the token URL to create a message. Your sender must provide a supported plain-text, form, or JSON body. An external service with a fixed, incompatible webhook payload may need a small adapter.

What are the limits?

Each token permits 60 requests per minute, and message text can be up to 40,000 characters. Send summaries and links rather than full logs. See the error reference for failed requests.

Does Fryll detect failed or missed jobs?

Your workflow or script determines the outcome and sends the notification. Fryll is the team conversation destination; a job that never starts needs an external scheduler or monitoring service to detect it.

How is this different from Slack incoming webhooks?

Both accept HTTP requests after setup. Fryll lets a conversation member generate a personal token in the conversation’s details. Slack’s incoming-webhook setup uses a Slack app and a configured webhook. Compare the documented setup paths in our Slack alternatives guide.

A place for your team

Give your next deploy a place to land.

Bring your people, your projects, and your notifications together in Fryll.

Start a workspace