DEV Community: Muhammad Soliman

Sending form submissions to Slack, Discord, Airtable and Notion

Muhammad Soliman — Fri, 02 Oct 2026 19:36:41 +0000

Every integration below has one setup mistake that returns success and delivers nothing. Here is each one, how to spot it, and the webhook payload I ended up designing around them.

I build a form builder, Seagit Forms, and most of the support questions I get aren't about forms at all. They're about a response that should have landed in Slack or Notion and didn't, while every dashboard said it worked.

After wiring up nine destinations, I noticed a pattern. Each service has exactly one mistake that a careful, correct-looking setup still hits, and it never throws an error. No 4xx, no exception, no red banner. Just silence.

Here are the ones worth knowing, whether you use my tool, someone else's, or write the integration yourself.

Slack: `200 OK` that posts nothing

You create a Slack app, add the chat:write scope, install it, copy the xoxb- bot token and a channel ID. You call chat.postMessage. Slack answers HTTP 200.

Nothing appears in the channel.

{ "ok": false, "error": "not_in_channel" }

Slack returns errors in the body with a 200 status. A bot with chat:write can't post to a channel it hasn't joined. Two fixes:

/invite @your-app        # in the channel

or add the chat:write.public scope, which lets the bot post to any public channel without joining. Private channels always need the invite.

The rule: never check response.ok on a Slack call. Check body.ok. A client that only looks at the HTTP status reports success for every misconfiguration Slack has.

Also set text on every message, even when you use blocks. Slack uses it for the notification and sidebar preview; without it the message arrives but notifies with a blank line.

Discord: `204 No Content` hides rejected messages

Discord channel webhooks are the easiest integration there is: one URL, no auth flow. POST JSON to it, get a 204.

The catch is that a 204 tells you almost nothing. Add ?wait=true to the URL:

https://discord.com/api/webhooks/<id>/<token>?wait=true

Now Discord waits until the message is created and returns it as JSON, or returns a real error if it was rejected (an embed field over the length limit, for example). Without it, a message Discord refused looks exactly like one it posted.

Treat the webhook URL as a password, too. Anyone holding it can post to the channel.

Airtable: one unknown column loses the whole record

Airtable's API matches fields by column name. If your payload has ten fields and one name doesn't match a column exactly, Airtable rejects the entire record, not just that field.

That makes renames dangerous. Someone tidies "Email address" to "Email" in the base, and from then on every submission is rejected.

What worked for me:

Read the table's schema first.
Send only fields whose names match a column.
Surface the unmatched ones to the form owner as a warning, rather than failing.

Also: don't send "" for blank answers. An empty string into a date, number or single-select column is itself a rejection. Omit the field instead.

Notion: `404` for an ID that is correct

You create an internal integration, copy its token, copy your database ID from the URL, and call the API. Notion answers:

{ "object": "error", "status": 404, "code": "object_not_found" }

So you re-check the ID. It's right. You re-copy it. Still 404.

The database exists. It just isn't connected to your integration. In Notion, open the database, then ••• → Connections → add your integration. Notion deliberately reports "not found" instead of "forbidden" so it doesn't confirm the page exists, and that sends everyone after the wrong problem.

Notion properties are also typed. A plain string into an email or date property is a 400 that loses the whole page, so read the database schema and shape each value to its property type first.

Microsoft Teams: the old connector is gone

If a guide tells you to add an "Incoming Webhook" connector to a Teams channel, it's out of date: Microsoft retired Office 365 connectors. You now create the URL through Workflows ("Post to a channel when a webhook request is received"). And note that the Workflows endpoint accepting your request is not the same as the card being posted. The flow runs afterwards.

The webhook: designing for the failures above

All of this pushed me toward making a plain webhook the most reliable destination, and treating every other integration as a notification rather than the record. This is the payload Seagit Forms sends to a webhook:

{
  "responseId": "response-1787712439855-b0t71",
  "formId": "g-1787690899982-nd90p",
  "submittedAt": 1787712439855,
  "data": {
    "firstName": "Ada",
    "teamSize": 12
  },
  "fields": [
    { "id": "firstName", "label": "First name", "type": "text" },
    { "id": "teamSize", "label": "Team size", "type": "number" }
  ],
  "respondent": {},
  "metadata": {
    "userAgent": "Mozilla/5.0 …",
    "referrer": "",
    "submittedFrom": "https://forms.seagit.com/forms/view/g-1787690899982-nd90p"
  }
}

The decisions behind it, which apply to any webhook you design:

responseId is an idempotency key. If you ever add retries, the receiver can drop duplicates.
fields travels with data. The receiver knows what each key means and its type, without a second API call to fetch the form.
Blank answers are absent, not null. That keeps the "don't send empty strings" rule from the Airtable section true downstream.
submittedAt is epoch milliseconds, not an ISO string. Pick one and document it; the bug is always a mix.
A failed delivery never fails the submission. The response is stored first, so a broken endpoint can't cost you an answer.

To test any webhook without writing a receiver, paste a webhook.site URL in as the endpoint and submit once. It shows the exact body and headers that arrived, which also confirms your auth header is spelled the way your real endpoint expects.

A checklist before you trust any integration

Does the client check the response body, not just the status code? (Slack)
Does the call wait for a real result? (Discord ?wait=true)
What happens when one field doesn't match: is one field dropped or the whole record? (Airtable, Notion)
Has the integration been granted access to the specific resource, not just authenticated? (Slack channel, Notion database)
Is there a record that doesn't depend on the integration, so a silent failure is recoverable?

If you'd rather not write any of this yourself, the setup guides for each destination walk through these exact traps, and webhooks and Telegram are free. Either way, I hope this saves someone an afternoon of re-copying an ID that was right all along.

Why our CI/CD is never allowed to deploy to production

Muhammad Soliman — Fri, 02 Oct 2026 19:35:53 +0000

A deployment model where every push gets its own isolated slot on Kubernetes, the main deployment is only changed on purpose, and promotion is an explicit act.

Most pipelines I've worked with end in the same place: merge to main, CI builds, CI deploys to production. It works until the day a green build is a bad release, and the only way back is another build.

When we designed the deployment model for SeaGit, a Kubernetes platform that runs in your own AWS account, we made one rule non-negotiable: CI/CD can create and update preview deployments, but it can never touch the main one. This post explains the model, because the idea works whatever tooling you use.

Instances and deployments

Two concepts carry the whole design.

An instance is an application's definition: image, resources, environment variables, DNS. It belongs to an environment (staging, production, and so on).
A deployment is one running copy of that instance. Each is its own Helm release with its own subdomain, for example pr-142.example.com.

An instance has several deployments. Exactly one is marked main (is_main: true). Main is the stable, production-facing slot. Every other deployment is an ephemeral slot: a preview, a test, a dark release.

instance: checkout-api            (environment: production)
├── main        → api.example.com          ← only changed on purpose
├── slot-a1f3   → a1f3.api.example.com     ← commit a1f3…
└── slot-9c2e   → 9c2e.api.example.com     ← commit 9c2e…

Because preview slots run in the same environment as main (same cluster, same add-ons, same network), a preview is a true dark release. It's production-like infrastructure with zero production traffic.

How a push picks a slot

When a GitHub push arrives, the target is resolved with three rules:

Same commit, same slot. If a deployment already exists for this commit SHA, it's re-triggered instead of duplicated. Re-running a pipeline doesn't spawn a second copy.
Otherwise, a new ephemeral slot, as long as the instance is under the environment's max_deployments_per_instance limit.
Never main. No rule in the resolver can select the main deployment.

The limit matters more than it looks. Preview environments are cheap individually and expensive collectively. A hard per-environment cap forces a decision ("reuse a slot or delete one") instead of a cluster that slowly fills with forgotten previews.

Getting a change into production

If CI can't deploy to main, something else has to. There are two explicit paths:

Promote. Copy the validated preview's configuration and run a fresh deploy into the main slot. Main keeps its name and URL, so nothing downstream changes.
Mark as main. Move the is_main flag to the preview itself. That slot becomes production, and future CI runs leave it alone and target the remaining slots.

Promote is the conservative choice: production stays where it is and gets a known-good configuration. Mark as main is the fast one: the exact pods you just tested become production, with no rebuild in between.

Both are deliberate actions, from the UI or the API. Neither happens because a build went green.

What this buys you

A bad merge can't reach users on its own. The worst outcome of a broken pipeline is a broken preview.
Testing happens on the real thing. Same environment, same add-ons, same network policy as production, not a lookalike staging cluster that drifts.
Rollback is boring. The previous main still exists as a deployment until you remove it.
Re-runs are idempotent. The commit-SHA rule makes "retry the pipeline" safe.

The trade-off is honest: someone has to press promote. For a team that wants every merge live within minutes, that's friction. For a team that has been paged at 2 a.m. by an auto-deploy, it's the point.

Doing this yourself

You don't need a platform to adopt the rule. With plain Kubernetes:

Deploy each branch or commit as its own Helm release, named from the commit or PR, with its own host in the ingress.
Keep production in a release your CI credentials cannot write to: a separate service account or a protected environment.
Make promotion a separate, manually triggered job that copies a validated release's values into the production release.
Cap the number of preview releases and delete old ones on a schedule.

Step 2 is the important one. "CI never deploys to production" only holds if it's enforced by permissions, not by convention.

Where SeaGit fits

SeaGit implements this model as the default: ephemeral preview deployments on managed Kubernetes in your own AWS account, built from GitHub pushes, with Promote and Mark as main in the UI and API. Your cloud provider bills you directly for compute, and there's a free plan with one cluster for trying it out (pricing). Azure and GCP support are on the roadmap.

Whether you use it or build the four steps above yourself, the rule is the same: let CI create as many previews as you like, and make production something a person chooses.